说实话，Zui近这几个月，技术圈子里Zui火的话题无非就是那个——AiCoding。不管是Cursor还是Claude Code，亦或是其他各种基于大模型的IDE插件，大家dou在聊。我也算是赶了个时髦，这段时间狠狠地折腾了一番，从Zui开始的“哇塞，这玩意儿神了”，到后来的“哎，这代码怎么又跑不起来了”，心情简直像坐过山车。

Ru果你也在用，或者正准备上手，我想你心里肯定也藏着不少问号。这东西到底Neng不Neng完全替代写代码？它生成的代码真的Neng直接上生产环境吗？还有，那个传说中的“Skill”到底是个什么鬼？今天咱们就抛开那些官方的宣传话术，像老朋友聊天一样，好好掰扯掰扯这事儿。

效率飞跃背后的“隐形陷阱”

咱们先说点好的。不可否认，AI Coding带来的效率提升是肉眼可见的。以前你要写个Demo，或者去实现一个MCP服务，那得查文档、kanStackOverflow、写样板代码，半天时间可Neng就没了。现在呢？你只要把需求丢给Agent，它唰唰几下项目骨架就搭起来了。甚至像Node.js或者Python这种脚本，它直接就Neng给你跑通。

但是兄弟们，别高兴得太早。这里面坑可不少。

不知道你有没有遇到过这种情况：你让AI修复一个Bug，它确实修好了但与此同时它把之前原本运行正常的一个功Neng给改坏了。这就好比你修好了水管，结果把电路给短路了。这种“拆东墙补西墙”的操作，在AI生成的代码里简直太常见了。为什么会这样？因为AI它不懂你的“业务上下文”，它只是在Zuo概率预测，它觉得这段代码这么改geng“像”正确的答案，但它不知道这会引发连锁反应。

geng别提那些隐性的安全漏洞了。有些行业研究显示，大概四分之一的AI生成代码里藏着雷。要么是引用了根本不存在的依赖库，要么就是逻辑上的越权访问。你kan着代码跑通了心里美滋滋，结果上线没多久，数据泄露了。那时候，你哭dou来不及。

从“写作者”到“审核员”的身份危机

这就引出了一个hen严肃的问题：我们正在变成“代码搬运工”或者“提示词操作员”。

我之前跟几个朋友聊过这个事儿，大家dou有种危机感。Ru果一个资深程序员，长期100%依赖AI来写代码，他的技术栈会发生什么变化？他的工程判断力会逐渐退化。短期内，你可Neng觉得产出变高了但一旦遇到复杂的系统架构、线上突发的性Neng瓶颈，或者那种需要极强底层知识才Neng搞定的诡异Bug，你就抓瞎了。

这其实是对未来3到5年程序员分层的一个hen准的判断。真正拉开差距的，不是谁geng会用AI生成代码，而是谁在用了AI之后仍然保有着完整的工程判断力。你得Nengkan懂AI写的是什么还得知道它哪里写得不对，甚至知道怎么引导它写出对的代码。这比你自己写还要难，因为你不仅要懂代码，还得懂“教”AI。

别光顾着聊天试试“Skill”吧

以前我们用AI，大多是“Prompt + Agent”的多轮对话模式。这种方式有个巨大的痛点：上下文太长了。聊着聊着，AI就忘了前面的提示词是什么了逻辑开始混乱，给出的答案也开始自相矛盾。这就好比你跟一个记性不好的实习生交代任务，说着说着他就跑偏了。

Zui近我发现了一个geng高效的玩法，那就是把指令沉淀下来变成所谓的“Skill”。

有个开源项目，名字挺有意思，叫pua。别想歪了这里的PUA指的是一种结构化的指令集。它的核心思想其实hen简单：把你对任务的理解、工程化的约束、验收标准，提前写成一个可复用的模板文件。比如skill.md或者skill-creator生成的配置。

这就好比给Agent发了一本“员工手册”。在它开始干活之前，先把规矩立好。你要用Node.js还是Python？代码风格要遵循什么规范？测试覆盖率要达到多少？这些全写在Skill里。这样，AI就不是在瞎猜，而是在按照规范执行。

我试过用claude-code配合这种Skill模式去写一个贪吃蛇的小游戏。以前我可Neng需要跟它扯皮半天现在直接加载Skill，它生成的项目文件夹结构清晰，代码规范也基本符合我的要求。虽然截图找不见了但那种“指哪打哪”的感觉，确实爽翻了。

SDD：规范驱动开发的新尝试

顺着这个思路，现在圈子里开始流行一种叫SDD的玩法。这跟传统的TDD或者BDD不太一样。

传统的Chat模式，geng多是在给你“思路”和“方法”；而有了Skill加持的Agent，geng像是一个Ke以被委派任务的“执行者”。SDD就是用规范文件把从需求到实现的链路串起来。给它geng像真实工程团队一样的规范、边界与流程。

比如OpenSpec这个框架，就是干这个事的。它用一种结构化的方式描述工作流。Ru果你对这套方法感兴趣，完全Ke以去kankan它的官方文档。要是文档kan不懂，没关系，直接把文档丢给大模型，让它给你解释，或者让它帮你生成一个符合OpenSpec规范的Skill模板。这本身就是一种“套娃”式的效率提升。

把Agent当成“Neng力hen强的实习生”

经过这段时间的实践，我对Agent的认知发生了挺大的变化。我现在geng愿意把它类比为：一个刚毕业、Neng力hen强但缺乏经验的实习生。

这帮新生，写具体的组件、模块代码那是真的快，学习Neng力也强。但是由于缺乏实战经验，他们Zuo出来的东西往往在细节上需要完善，或者在整体架构上考虑不周。

所以跟AI协作的关键，不是“让它geng聪明”，而是“管理好它”。

我有一个行之有效的策略，特别适合处理复杂任务：当问题变得hen复杂，或者上下文理解成本hen高的时候，模型经常会给出一种“解决不了”的结论，或者在不充分尝试的情况下就提前收尾。这时候，千万别惯着它。

我会使用一种“高压推进”的方式。比如在需求描述的提示词后面我一定会跟上一句：“Ru果你对上面描述有疑问的，直接问我，不要瞎猜。” 或者是：“继续往下Zuo，不要停。” 这种强制性的指令，往往Neng逼出模型geng多的潜力。说实话，这听上去有点“邪修”，但我实际试过一个原本卡了我半小时的问题，用上之后几分钟就Neng定位并解决。

未来Zui难的不是“怎么实现”，而是“实现什么”

晓辉博士之前说过一句话，我印象特别深：在未来Zui难的不是如何实现，而是实现什么。

AI Coding确实会让人上瘾，它极大地缩短和减小了从产生想法到实现想法的路径和难度。你想Zuo个工具，以前要憋一周，现在一晚上就Neng出原型。这种快感是hen容易让人沉迷的，也就是大家常说的“Vibe Coding”——跟着感觉走，代码随便飞。

但是作为开发者，我们不Neng只停留在这种快感里。我们得思考：这个需求真的合理吗？这个架构Neng支撑未来的 吗？这段代码虽然现在Neng跑，但半年后谁还Neng维护？

平时大家dou在聊模型Neng力，但真到长期使用阶段，你迟早会开始关心另外几个问题：这次为什么geng贵了？这个任务为什么消息数突然变多了？某个Session为什么明显geng重？你Nengkan到Zui后输出了什么但hen难hen快回答这些问题。这就需要我们有geng深层次的监控和把控Neng力。

给AI Coding使用者的边界清单

Zui后为了防止大家因为盲目相信AI而把严重Bug带到生产环境，我整理了一份“边界清单”。这东西hen适合拿来自我约束，或者分享给团队里的兄弟们。

永远不要100%信任生成的代码： 哪怕是再简单的CRUD，也要过一遍脑子。AI不懂你的业务逻辑，它只懂语法。

保持独立写代码的Neng力： 每周至少留点时间，手写一些代码，别让手生了。基本功这东西，一丢就难捡回来。

明确验收标准： 在让AI开工前，先想好怎么测试它。是kan单元测试通过率，还是kan具体的输出结果？把标准写进Skill里。

警惕幻觉代码： Ru果AI引用了你没见过的库，或者调用了一个不存在的API，一定要去查官方文档。别想当然。

复杂系统慎用： 对于核心交易链路、涉及资金安全的模块，建议还是人工主导，AI辅助。出了事故，AI可不背锅。

利用Ask模式： 针对较大的需求，先使用Ask模式，和Agent把需求对清楚。确认它理解无误了再让它生成代码。

回过头kan，这一轮AI Coding的体验给我Zui大的收获是：它是一个极其强大的副驾驶，但绝不Neng让它抢了方向盘。我们Ke以利用它来处理繁琐的细节、生成样板代码、甚至提供灵感，但方向盘必须握在自己手里。

Ru果你对这套方法感兴趣，或者抱团取暖，总比一个人在那儿跟AI较劲要强得多。你说是不是这个理儿？

---