1. 先想清楚AI代码助手的定位与业余开发的现实我最早接触AI辅助编程是抱着让AI替我写代码的心态去的。结果第一个项目就翻车了——我让AI帮我写一个网页数据抓取工具它生成了看起来非常完整的Python脚本带异常处理、带重试机制、带日志输出我几乎没改就扔进了生产环境。第二天起来一看程序跑是跑起来了但抓回来的数据全是空值因为目标网站改版后数据结构早变了AI并不知道这件事。那次之后我花了一整周在重新理解这个项目。后来我想明白了一个道理AI写代码这件事本质上是把从零到一的成本压缩了但从一到一百的工作一点没少——你要理解需求、要定义边界、要设计数据结构、要处理异常分支、要测试验证。这些环节里AI能帮上忙但前提是你得知道自己在干什么。业余开发者在这个场景里有天然的优势也有天然的短板。优势是你没有KPI压力可以从容试错短板是你通常没有成熟的工程经验容易把AI生成的东西当成品直接用。我见过不少业余小伙伴让AI写了个爬虫就跑结果反爬策略一变就抓瞎让AI写了个前端页面就上结果移动端一打开布局全乱。这不是AI不行而是使用方式有问题。我给AI代码助手的定位是一个知识面极广、速度极快、但完全不懂业务逻辑的结对搭档。它像一个读过无数开源项目的实习生你问它什么它都能答上几句但它没有判断力不知道你真正要什么。你让它写一个登录接口它能把JWT、OAuth、Session全给你铺一遍但你得告诉它这是内部工具只要Session就够了安全要求没那么高。所以业余开发的第一个核心能力不是会写代码而是会描述边界。AI的能力边界由你画的边界决定你描述得越清晰它产出的东西越可控。这个能力是可以练的后面我会专门讲提示词的拆解方法。另外我想纠正一个流传很广的说法AI能替代程序员。至少在我接触的所有真实项目里这个说法都不成立。AI目前做的事情是代码生成和信息检索它不能替你梳理需求、不能替你做架构决策、不能替你验收结果。尤其对于业余开发者来说AI越强判断力越值钱——判断什么该让AI做、什么该自己做判断AI生成的方案是否合理、判断哪里可能藏坑。这些判断力来自于一次次真实的踩坑没有捷径。顺便说一句我观察到身边很多业余开发者——包括我自己早期——陷入过一种AI焦虑觉得别人用AI一天能写完一个应用自己还在慢慢摸索基础是不是要被淘汰了。实际完全不是这样。越是能用AI快速出活的人越依赖底层的判断力而判断力恰好是需要时间沉淀的。业余开发者最大的资本就是时间充裕、可以慢慢磨别被速度焦虑带偏节奏。所以这篇经验整理我不会给你一份万能提示词大全或者AI开发速成指南。我会从真实项目的角度拆解我在业余开发过程中用AI碰到的实际问题、摸索出的协作方式以及那些让项目从能跑变成能用的关键细节。适用于想认真做点东西的业余开发者也适用于刚接触AI辅助编程、想要系统建立工作流的在校学生。下面我们一项一项来。2. 从模糊想法到可控任务提示词拆解与上下文管理2.1 为什么业余开发者最容易卡在描述需求我自己观察到一个高频场景业余开发者心里有个模糊的想法——我想做个工具管理我的收藏夹我想写个脚本自动整理下载文件夹——然后直接打开对话窗口输入帮我写个程序。AI确实会回应给你生成一段通用代码但这段代码几乎一定是跑不通的。不是AI笨是它缺少太多关键信息运行环境是什么数据从哪里来输出到哪里去错误怎么处理要不要图形界面专业开发者团队里这些信息来自需求文档、技术评审、原型图。业余开发者没有这些流程所以必须自己把模糊想法翻译成可控任务。这个过程才是业余开发真正的核心工作AI写代码只是最后一步的执行环节。我实践中比较好用的拆解方法是把任务拆到AI只需要做一次翻译就能完成的颗粒度。也就是说不要指望AI理解你的宏大愿景你要把愿景拆成一个一个具体的、可验证的小步骤。比如管理收藏夹这个想法第一个可控任务是从浏览器导出的HTML书签文件里提取所有URL和标题输出为JSON。这个任务描述已经具体到输入是HTML文件输出是JSON操作是解析和提取。AI面对这种任务产出的代码基本可以一次跑通。2.2 可控任务描述的四大要素根据我反复试验的经验一个AI能稳定产出的任务描述至少包含以下四要素技术栈与运行环境明确告诉AI用什么语言、什么框架、目标平台。比如用Python 3.10只使用标准库和用Node.js Express会带来完全不同的代码。业余开发最容易忽略的是版本信息AI默认会选它训练数据里最常见的版本往往和你的环境不一致。输入与输出的定义说清楚输入是什么格式、输出要什么格式。数据是CSV还是JSON结果是打印到终端还是写入文件文本是中文还是英文这些细节直接决定代码的可用性。约束条件有哪些不能做的不需要UI不允许用第三方依赖必须离线运行数据量级多大这些约束能防止AI写出功能上正确但实际不可用的方案。验收标准你怎么判断这个任务完成了比如程序运行后生成result.csv包含id、title、url三列行数与输入文件相同。这个标准既是给AI的也是给你自己的——你可以拿它做验收测试而不是靠看起来差不多了判断。我实际给AI的一个提示词示例是这样的用bash代码块展示后面讲多文件项目时还会展开我需要一个Python脚本来处理书签导出文件。 输入一个HTML文件Chrome 导出书签生成的格式结构包含嵌套的文件夹层级。 输出一个JSON文件按文件夹层级组织每个书签包含title和url字段。 约束 - 只使用Python 3.10标准库不引入外部依赖 - 源文件可能是深层嵌套需要递归解析 - 书签条目可能缺失title或url缺失时跳过并在输出中添加warnings数组 验收标准 - 脚本运行命令python3 parse_bookmarks.py input.html output.json - 输出JSON格式正确可以用json.load()读回 - warnings数组会列出所有被跳过的条目及原因 请生成完整代码包含必要的类型注释和docstring。这个任务描述本身花不了三分钟但AI产出的代码质量比我以前直接说帮我解析Chrome书签HTML高了一个量级——因为每一个边界条件它都知道了不用瞎猜也不会出现跑起来才发现少处理一种情况的问题。2.3 多文件项目里的上下文管理上面处理的是单文件小脚本。到了真正的项目——带多个模块、带配置文件、带前端后端的——提示词技巧就不够用了核心变成了上下文管理。AI对话窗口的上下文是有限的你不可能把整个项目的所有文件都扔进去让它理解全貌。而且就算它能读完一次性让它改十个文件也非常容易崩。我的做法是手工为AI构建一个最小上下文包。这个最小上下文包包含项目的目录结构用tree命令生成即可相关模块的完整代码要和当前任务相关的不是全部文件当前要修改的文件的完整内容一份简短的项目说明这是做什么的、模块之间怎么依赖比如我之前做一个简单的书签管理Web应用时前后端加起来有二十多个文件。要加一个新功能——给标签添加编辑功能——我不会直接把二十个文件全丢给AI而是先说明这个应用是Flask后端 原生JS前端后端路由在app.py前端在static/js/main.js数据存储在bookmarks.db然后把这两个文件的完整代码贴进去再描述具体需求。这样AI看到的是局部代码 全局说明既不缺上下文也不会信息过载。我还发现一个很实用的技巧在项目根目录放一个CONTEXT.md记录项目的技术栈、目录结构、核心设计决策、常用命令。每次和AI对话时先把这份文件的内容复制进去再提具体问题。这相当于给AI一个快速上手文档它每次都能很快进入状态而不是猜你用什么框架、代码放哪里。这个习惯是从我维护一个开源小项目开始的当时issue里来了个新贡献者我不知道怎么跟他同步项目背景就写了个CONTEXT.md后来发现把同样思路用在AI对话上出奇地有效。2.4 Agent开发的现实拆任务比写提示词更重要这两年AI Agent这个词特别热很多业余开发者以为Agent就是给AI一个大目标它自己拆解自己执行。我基于自己用LangChain4j这类框架做过几个Agent原型项目的经验必须泼一盆冷水当前Agent框架能拆解的是执行步骤不是业务目标。什么意思呢你给Agent一个任务帮我调研竞品定价它能拆成搜索网页、提取内容、总结要点但它不能替你定义竞品是谁、定价里哪些信息有价值、总结给谁看。这些业务判断最终还是得你自己做。在代码开发场景里的应用是Agent框架可以帮你按顺序执行读取配置→调用API→写入结果→输出日志这种流程型任务适合做批量处理、流水线操作。但如果你让它开发一个完整应用它只会生成一堆结构看起来正确、但彼此之间根本没有真实依赖关系的代码文件组成一个无法运行的骨架。所以我现在的策略是流程用Agent判断用自己。比如批量重构几十个文件里的命名风格、统一日志格式——这种有明确规则、重复性高、出错影响可逆的任务放心交给Agent框架。但涉及到业务逻辑调整、数据结构设计、异常处理策略——这些会对应用行为产生深远影响的决策必须亲力亲为。这不是对AI能力的不信任而是对风险的管理——业余项目出事也没人帮你兜底一开始就控制好风险承担的范围是最省钱的做法。3. 让AI接手重复劳动日常开发流程中AI的实用切入点3.1 识别低风险高重复的任务在聊具体切入点之前先讲一个我给自己定的原则AI处理的任务必须满足低风险高重复两个条件。低风险是说任务出错带来的影响可控——比如生成一个展示页面出错最多是样式难看不会丢数据高重复是说任务模式固定、每次操作差不多——比如把API返回的字段映射到前端表格。违反这个原则的典型场景是让AI直接写数据库迁移脚本。数据库操作出错带来的影响不可逆而且你很难靠肉眼审查验证正确性。我见过有人让AI生成一个DELETE语句的变体少了一个WHERE条件差点把整个表清空。这种风险不值得冒数据库操作永远要手写、要review、要在测试库先跑。那业余开发场景里哪些任务适合交给AI我列出自己用得最多、收益最高的几类。3.2 前端的页面骨架与样板代码前端开发是AI辅助收益最大的领域因为它有大量看起来不一样、本质上差不多的工作。你让AI生成一个后台管理系统的表格页它给你的代码往往可以直接用——因为这种页面无非是获取数据→渲染表格→处理空状态→加个删除按钮模式太成熟了。我每次做前端页面时的工作流是这样的先在对话里给出设计草图Text描述版比如左侧边栏放导航顶部是搜索栏主区域是数据表格右下角悬浮添加按钮让AI生成HTMLCSS骨架然后我自己填充业务逻辑最后再让AI做细节调整。这样我花在搭架子上的时间从两三小时压缩到二十分钟把精力留给真正需要思考的部分。还有一个对业余开发者特别友好的用法让AI解释现成代码。前端生态迭代太快看到一个新的框架、新的API原生的做法是查文档、翻教程现在可以先把代码丢给AI问它这段代码在做什么每一步为什么这样写有什么过时的用法我在遇到不熟悉的库或框架时经常用这个方式快速建立理解比自己对着文档猜效率高太多。3.3 嵌入式开发中的芯片手册解读可能有人觉得AI只能用在Web开发其实我在嵌入式开发里也找到了一些好用的场景。这行最大的痛点是芯片手册和寄存器描述又长又绕信息密度极高但检索起来极慢。AI在解读这类文档上表现意外地好。比如我在调一个传感器的I2C接口时手册里的时序图和数据格式描述看得头疼。我把关键段落贴给AI问它这个传感器的初始化流程应该是什么样的读数据的寄存器地址是多少校验和的算法是什么AI给出的摘要虽然不能完全替代手册核对但能极大加速理解过程把两三天的摸索压缩到半天。这类场景的核心价值是AI可以把专业领域的人话翻译成工程师能懂的话。嵌入式开发里还有大量这种翻译需求——协议文档、数据手册、勘误表、参考代码。这些内容不是不能自己看而是消化时间太长AI能帮你先建立起全局理解再针对性地去核对细节。3.4 调试排错让AI做报错的第一个分析师每次遇到编译错误或者运行异常我现在的习惯是先把完整的报错信息、相关代码、运行环境三样东西整理好原封不动丢给AI让它做第一轮排查。AI会给你列出几个可能的原因和对应的验证方案。这个过程的价值有两个一是快速覆盖常见原因二是帮你建立排查思路的框架。但我必须强调一个前提你要能判断AI给的分析质量。我遇到过AI一本正经解释一个其实和问题完全无关的报错原因也遇到过AI把两个不同版本的库混在一起分析导致逻辑完全混乱。所以AI的分析可以当参考线但最后的验证必须自己做。好用的做法是给AI加上验证任务请给出三个可能原因并告诉我每个原因应该用什么实验去验证。这样你就拿到了一个排查路线图按着路线图一个个验证比自己瞎猜效率高得多。另外提一下代码诊断插件。这类工具能实时分析你的代码在写的时候就标记出潜在问题有点像AI驱动的编译警告。我用了之后感觉对业余开发者帮助很大因为它能在你还没意识到出问题之前就把问题摆出来省去后面Debug的时间。不过这些插件的建议也不是每条都准确它的定位是提示不是权威结论——当它和你的实际测试结果冲突时请以测试结果为准。3.5 注释、文档与测试用例——被低估的三件事业余开发者和专业开发者最大的区别之一是对文档和测试的态度。专业项目里文档和测试是硬性要求业余项目里几乎没人做。我的经验是业余项目里可能不需要完整的测试套件但一定要有关键路径的冒烟测试和让两个星期后的自己看得懂的注释。这两个需求AI都能帮上忙。写注释时你可以把代码块丢给AI说帮我为这段代码写注释解释函数行为和关键变量的用途不要逐行注释要有逻辑层次。AI生成的注释质量通常不错你只需要核对它说得对不对。冒烟测试就更简单了——你给AI描述应用的核心流程让它生成一个测试脚本覆盖启动、调通关键接口、退出这条主路径。真的这个习惯能救你很多次。我有个小工具项目放了三个月没碰回来后跑一下冒烟测试五分钟就知道还能不能正常用不用从第一行代码开始回忆。还有写commit message和代码review。这两个需求在开源项目里尤其重要——如果你打算把业余项目公开出去一份清晰的commit history和合理的pull request描述能帮你吸引贡献者、减少维护负担。AI在这两件事上简直是神器你给它git diff它能总结出这次改动做了什么、为什么、有什么影响。虽然偶尔会总结得文不对题比如改动是修bug它总结成了添加新功能但整体上比我手写快太多也规范太多。4. 生成代码不等于能跑AI产物的验收、修复与安全底线4.1 AI幻觉的典型表现一本正经地编造API我在第1节提到爬虫脚本抓空数据的案例那是AI幻觉的典型场景——它用了目标网站的最新结构来「编」逻辑但那个结构实际上已经不存在了。更常见的幻觉表现是编造不存在的APIAI的训练数据里有大量不同版本的库文档它在生成代码时可能把两个版本混着用给出一个实际上不存在的方法或参数。这类问题在相对冷门的技术栈里尤其高发。比如用比较新的框架版本时AI可能还在用旧版的写法用比较小众的库时它可能想象出一个看似合理但实际不存在的接口。对待这种情况我的原则非常简单AI生成的代码里用到的每一个API都要在官方文档或实际环境里验证存在。验证方式可以是查文档、在IDE里看自动补全是否符合、或者跑一行最小样例。不能因为编译没报错就放心很多AI幻觉代码是运行到某个分支才会触发报错。我自己踩过的一个具体案例用LangChain4j开发Agent时AI生成了一段Embedding模型初始化的代码用了一个听着非常合理的类名和方法名编译也没问题但一运行就抛NoClassDefFoundError。排查了半天发现那个类属于某个optional的依赖模块需要额外引入而AI根本不知道我这个项目的依赖配置。从那以后我要求自己做到两点一是每个外部依赖都明确核对版本和maven坐标二是每段涉及第三方库的代码都先跑一个最小可复现的demo再往项目里集成。4.2 验收清单不跑测试就上线的都是赌博每次AI生成代码之后我都有一个验收清单。虽然不是每次都全走一遍但核心几项一定会做编译/运行通过是最基础的这道关过不了别的都别提。边界情况测试是业余开发最容易漏的我给书签解析脚本就补了几个测试空文件、全部条目都缺title的、双层嵌套的——当时AI生成的代码在空文件上直接崩了因为没处理文件内容为零的分支。错误路径测试看AI没有处理出错了该怎么办。比如网络请求失败、数据库连接断开、用户输入非法数据。很多AI生成的代码在理想路径上走得很顺一到异常分支就裸奔。二次运行测试看代码是否有副作用。我有个工具脚本第一次运行正常第二次运行报错因为AI在脚本里重复创建了目录。这种问题只能靠真实验证出来。做这四步验收看上去费时间但实际上比上线后再Debug省得多。我建议你把验收标准的描述放在提示词里让AI生成代码时自己就考虑这些情况这样验收环节其实会轻松很多。4.3 安全底线别把敏感信息交给AI这一节想聊一个不那么技术但极其重要的经验——不要往AI对话里贴敏感信息。具体来说是美国IP访问受限、API密钥、数据库连接串、用户个人信息这四类。很多人习惯把完整的配置文件、env文件直接贴给AI让它帮忙排查问题。这其实是很大的安全隐患。先不说信息可能被第三方留存哪怕是少数的泄露案例也足以让你后悔。业余项目虽然通常不是高价值目标但一旦涉及真实用户数据风险等级完全不同。我的做法是涉及敏感信息的地方一律用占位符替换。比如要排查数据库连接问题我会把连接串改成mysql://user:passlocalhost:3306/testdb这样的假数据保留格式去掉真实内容要排查线上报错我只贴报错堆栈和环境信息不贴任何配置文件中含密钥的部分。还有一点不要让AI生成的代码里出现密钥硬编码。AI默认会把示例配置里的密钥直接用到代码里你要养成习惯所有密钥一律从环境变量或配置文件读取。我在开源项目里已经见过太多把API密钥提交到公开仓库的案例了这坑真的没必要踩。4.4 Git是业余项目的后悔药我特别想对业余开发者喊一句学会用Git越早越好。很多业余项目一开始就少了Git这道保险导致一个问题AI生成的代码你不知道哪些是好的、哪些是坏的想回退都不知道怎么回退。我自己的习惯是每次让AI做一次比较大的改动前先git commit一下当前状态。这样如果AI改崩了直接checkout回来不用手动撤销一堆改动。这里面有一个很实用的技巧使用AI生成commit message。算不准GitHub Copilot这种工具怎么用但我知道至少可以在对话里贴git diff让它总结。虽然有时总结得不准确但比什么都不写好至少能让你快速浏览改动内容、判断是否合理。另外一个Git配合AI的好用法是通过git diff来审查AI的改动。AI改完代码之后运行git diff看每一行改动这个习惯能让你确切知道AI改了哪里、为什么改。我总是建议业余开发者不要只看结果能跑要看改动内容。因为AI的代码可能能跑但用了你不想用的方式或者引入了你喜欢的方式之外的模式——只有看了diff才知道不然等到以后维护才后悔。5. 用AI但不依赖AI业余开发者自我提升的几个习惯5.1 让AI当老师而不是当写手我观察到一个特别普遍的现象用AI辅助开发一段时间后很多人遇到问题第一反应不是自己思考而是直接问AI。这会导致一个严重后果——基础能力退化。如果一直让AI帮你写代码、帮你排查问题你的大脑会逐渐停止编程模式的运转。但AI本身是中性的关键在于你怎么用它。我自己的方式是让AI当老师而不是当写手。具体来说就是让AI解释概念而不是让它直接给方案。遇到不懂的API或设计模式先问这个是什么、为什么这样设计、和其他方案比有什么优劣势让自己先理解然后再动手写。让AI出练习题让它设计一些小需求让你自己实现。请给我出三个针对文件处理的小项目练手要求用到递归和异常处理难度适中。这种用法等于免费请了个私人教练。让AI当reviewer而不是当author。写完代码后让AI review你的代码指出潜在问题——比自己闭门造车高效得多。这个习惯的本质是把AI当学习工具而不是生产工具。业余开发的最终目标应该是提升自己的能力而不是单纯做出一堆依赖AI才能维护的项目。如果项目必须靠AI才能继续改那说明你对它的理解还不够深。5.2 读报错信息的能力比写代码更值钱如果让我只选一个业余开发者必须掌握的技能我会选读报错信息。这个技能听起来很基本但实际操作中是很容易被跳过——很多人遇到报错就直接把报错丢给AI让AI解释是怎么回事。但AI的解释你永远无法完全信任因为你没有自己分析的能力就无法判断AI分析得对不对。我的建议是遇到报错先花三分钟自己读一遍尝试理解发生了什么。报错信息里通常有类型、有位置、有触发条件这三样信息足够你自己做初步判断。实在看不懂了再去查资料、问AI。这样每次报错都变成了学习机会你的排查能力会快速成长——而不是永远停留在复制粘贴报错给AI的阶段。说个具体的Python的Traceback很多人看到一堆堆栈直接慌了。但核心信息就是最后一行——什么类型的错误、发生在哪一行。你只需要把最后一行读懂就能定位到问题所在。前面的堆栈信息是在告诉你经由哪条调用链走到这里排查复杂问题时才有用。我见过太多人把整个堆栈截图丢给AIAI分析半天也找不出问题的——因为问题往往很简单就是最后一行告诉你的那个根本不存在的变量名。5.3 维护自己的代码笔记业余开发生涯里会遇到无数次这个问题我以前好像解决过的困境。我当时没记录下来后来费了很大的劲重新摸索。现在我养成了一个习惯每个项目里维护一份NOTES.md记录踩过的坑、解决思路、关键技术决策。这份笔记的直接受众是我自己但换个角度——它其实也是未来给AI的上下文素材。当AI对话没法回答你这个依赖版本跟什么冲突时你可以翻翻NOTES.md看看之前的记录去跟AI同步当你把NOTES.md作为背景资料贴给AI时对话质量会高很多因为AI再也不用从零了解了。这个习惯的成本极低每次踩坑后多写两句话价值却很高。5.4 警惕AI依赖症的三个信号最后想提醒大家注意一下自己是不是已经开始依赖AI过度了。我总结了三个信号出现任意一个就要警惕不经过思考就直接问AI——遇到问题第一个念头是问AI而不是先自己想想。哪怕思考结果不对这个过程也在训练你的能力。看不懂自己项目里的代码——打开自己项目发现大量的代码是自己生成的但看不太懂。这说明项目已经超出你的掌控范围了这时候要停下来把代码搞懂再进行下一步否则项目迟早会因为无人能修而废掉。离开AI就不会写代码了——你可能会发现自己手动写代码时变得非常犹豫、频繁查资料。这种情况说明基础已经开始退化要赶紧减少AI的使用频率回到手写代码的状态。这三个信号我前几年全都出现过也都是靠强制自己回到手动模式才缓过来的。AI辅助开发的正确姿势不是把AI当拐杖而是把AI当加速器——你的方向感和驾驶技术还是自己说了算。5.5 业余项目的正确终点敢交付也敢弃坑最后想聊一点心态层面的东西。业余开发者做项目最常见的结局不是完成而是无限期搁置。我之前积攒了一堆只写了开头的项目每一个都技术选型完毕、写了代码但没一个真正跑过了全部的流程。后来我想明白一个问题业余项目的意义不在于完成在于跑通。哪怕是一个非常小、非常简单的项目完整跑了一遍需求梳理→架构设计→开发→测试→部署→维护的全流程收获的东西远远大于做十个永远停在开发阶段的项目。所以我现在的做法是每次只take一个很小的项目做到完成。哪怕它很简单完成后的信心积累和经验复盘都非常有价值。当然敢交付的另一面是敢弃坑。如果一个项目你已经确定了不值得继续维护不要因为写了这么多代码就舍不得扔。你的时间和精力才是最宝贵的资源及时止损比囤积半成品有价值得多。最后分享几个我一直在用的实操小习惯写到这里这篇经验整理已经差不多了。作为收尾我把自己一直在用的几个小习惯列给你都是那种说不上多高级、但真的有用的东西。第一个是用最小可运行示例验证AI思路。每当AI给出一个设计方案我先按它的思路写一个几十行的最小demo跑通了再往项目里集成。这能帮我拦截90%以上的方案级问题比直接按AI方案改完再Debug高效太多。第二个是定期清理对话上下文。同一个功能开发时间长了对话窗口越滚越大AI的回复质量和运行速度都会下降。我会在项目里程碑时开一个新对话把CONTEXT.md和当前进展贴进去保持对话上下文短小精悍。第三个是人为设置一些必须自己写的边界。比如核心算法、数据库操作、密码相关逻辑这三类永远自己手写不让AI碰。这样即使AI再来个幻觉也不会伤到项目的根基。关于AI辅助编程我的总体体会可以用一句话概括AI改变了写代码的速度但没有改变开发的本质。需求的梳理、风险的判断、质量的把控这些东西在任何时代都是核心能力。业余开发者在AI时代拥有的最好机会是以更低的门槛真正进入工程世界——但门槛低了不代表能力会自己长出来。希望这篇整理能帮你少走一些我走过的弯路早点找到自己和AI协作的舒服节奏。
