说实话，Zui近这阵子，不管是技术圈还是朋友圈，大家dou在聊AI写代码的事儿。好像只要装了个AI IDE，按几个回车键，就Neng自动生成一套完美的系统，程序员从此就Neng躺平喝咖啡了。但现实往往比理想骨感得多，甚至有时候还带着点儿“坑爹”的味道。

hen多人问我一个特别直击灵魂的问题：既然有了AI辅助，我们写出来的代码还需要手动去调整、去审核吗？

我的答案可Neng不那么“科幻”，但绝对真实：必须的，而且这步可Neng是整个开发流程里Zui不Neng省的。

咱们得承认，现在的AI确实聪明，它Neng理解你的意图，Neng吐出kan起来hen漂亮的代码块。但是它毕竟是个“机器”，它没有你的业务上下文，也不懂你那个项目里那些只有老员工才知道的“潜规则”。

你想想kan，AI帮你改完代码，直接就提交了？这简直就是在裸奔。我自己的习惯是不管AIkan起来多靠谱，在触发那个所谓的“质量门禁”之前，有一个环节是绝对不Neng跳过的，那就是——人工审核代码。

现在的AI IDEZuo得dou挺人性化，每次它帮你改完东西，界面上dou会弹出一个“改动点”面板。这个面板就像是一个清单，列出了它动了哪些文件，改了哪一行。你得耐着性子，逐个文件、逐行地去Diff一下。

为什么要这么麻烦？因为AI写的代码，大部分时候逻辑是对的，但它偶尔会自作聪明。比如你没要求它改的地方，它顺手给你“优化”了；或者在某些边界条件的处理上，它完全没get到你的业务意图。这些问题，只有你那双肉长的眼睛亲眼kan一遍才Neng发现。机器检查只Nengkan语法，kan不懂“业务坑”。

有人可Neng会说：“那是因为你调教得不好。” 哎，这话说到点子上了。AI就像一个刚入职的聪明实习生，Neng力hen强，但Ru果不给他一本《员工手册》，他就会按照自己的理解去干活，结果写出来的东西可Neng跟你的项目风格完全不搭。

所以我干了一件kan起来hen“笨”的事儿：我写了600多行的工程规则文件。

这600多行不是废话，而是用来告诉AI：“在我这个项目里你应该怎么干活。” 没有这些规则，AI就是无头苍蝇；有了这些规则，它才是你的得力助手。这600多行规则，配合上我的Skill，简直就是天作之合。

规则文件覆盖的面其实挺广的，咱们随便挑几个说说：

这事儿kan起来小，但真的hen影响心情。比如命名规范，你是喜欢驼峰还是下划线？注释风格是文档注释还是行内注释？方法长度有没有上限？类的职责边界在哪里？

举个例子，我个人比较强迫症，我规定一个方法绝对不Neng超过30行，一个类不Neng超过200行。Ru果AI在Code Review的时候发现超了它就会直接报出来。这就好比给AI设了个红绿灯，它知道怎么去守规矩。

这点在稍微大一点的项目里太重要了。哪些层Ke以调用哪些层？DTO和Entity之间必须用转换器，严禁直接赋值！Controller层里要是出现了一行业务逻辑，那必须得打回。

这些规则存在的意义，不仅仅是好kan，geng是为了让AI在Zuo“影响面分析”的时候，Neng够理解你的架构分层。它懂了你的架构，给出的影响范围分析才准确，不然就是瞎指挥。

Zui怕的就是AI生成的单元测试只测“Happy Path”，那这种测试跟没测有什么区别？

我在规则里写得清清楚楚：单元测试必须覆盖哪些场景？正常路径、边界条件、异常情况，一个dou不Neng少。测试方法的命名规范是什么？Mock的使用原则是什么？AI生成测试的时候，会严格按照这些标准来绝对不会给你生成那种水水的测试用例。

哪些问题是必须修复的？比如SQL注入风险、未关闭的资源，这种是红线，碰了就得死。哪些是建议修复的？比如代码写得太啰嗦，Ke以用geng简洁的Lambda表达式替代。

AI在Code Review的时候，会自动区分Severity级别。它不会把所有建议dou当成必须改的Bug来报，不然你就得被警告信息淹没，根本分不清主次。

我一直觉得，咱们程序员用AI，会比其他职业的人高效hen多。为什么？因为我们天然就有模块化、组合的思维。非程序员可Neng会想要一个“帮我把所有事情douZuo了”的大按钮，但程序员会本Neng地把这个大任务拆成一个个可复用的小模块，然后用一个编排层把它们串起来。

这就是我设计Skill的核心理念：单一职责原则。

道理hen简单：一个方法只Zuo一件事，才好被不同的地方调用。Skill的设计也是一样。我绝对不会搞一个大而全的Skill，里面塞满了“跑测试+审查+分析影响面”。

假设你有一个只负责跑单元测试的UT Skill。这多好用啊？我在重构场景里Ke以用它，写新功Neng的时候Ke以用它，修完Bug之后也Ke以单独调一下验证。但Ru果把所有功Nengdou塞进一个大Skill里那我只想跑个测试的时候，还得忍受它在那儿分析半天影响面效率低得要命。

粒度小带来的好处就是：每个Skill独立可用，同时又Neng被一个总调度Skill编排成流水线。

目前我实际在用的，主要有这么三个Skill，每一个dou只干一件事：

1. Impact-analysis

这个Skill的作用就是分析影响面的。你Ke以在写代码之前调用它，评估一下这次改动会牵扯到哪些模块；也Ke以在写完代码、人工审核之后作为第一个节点去使用，确保你的改动没有“炸”到别的地方。

2. Codereview

这个Skill关注的是geng高层次的东西。它不是在检查你有没有少写分号，而是在kan：这段代码的设计合不合理？有没有安全隐患？性Neng上有没有坑？可维护性怎么样？这些是机器静态检查不容易覆盖到的，需要AI从代码审查的角度Zuo一次深度分析。

3. Commit

这是流水线的终点。它的完整流程其实挺复杂的：分析本次变geng → 生成Commit Message → 弹出确认 → 执行Commit → Pull远程Zui新代码 → Ru果有冲突则辅助解决 → Push。

这个Skill之所以单独拆出来而不是直接写在Quality-gate里是因为我有时候只想提交代码、不需要跑全套检查。这时候，直接输入/commit就行，多快好省。

有了上面这三个子Skill，我就需要一个“带头大哥”来把它们串起来。这就是我的/quality-gate。

这个Quality-gate就是一个总调度Skill，配置在SKILL.md里。它的职责hen明确：按顺序调用上面3个子Skill。任何一个环节不通过它就中断并报告问题；只有全部通过才会进入Zui后的Commit环节。

我的Zuo法其实特别简单：在Agent聊天窗口里描述完需求，写完提示词，代码改完之后我只需要输入一个命令：/quality-gate。

当然在跑这个命令之前，我Yi经Zuo完了那件Zui重要的事——人工审核。kan完所有改动，确认没问题后我会在聊天窗口里告诉AI“改动确认，继续”。这样保证进入自动化流水线的代码，Yi经是我亲眼审核过的。

这时候，一个/命令下去，全套检查跑完，Zui后确认一下就提交。这就是粒度小带来的好处：每个Skill独立可用，同时又Neng被一个总调度Skill编排成流水线。

改代码的风险其实有三层，Zui让人头大的莫过于代码冲突。

这里有个细节值得大家注意。冲突其实不是发生在Commit的时候，而是在Push之前Pull远程代码的时候。试想一下Ru果你的队友在你改代码的这段时间里也Push了新代码，而且好死不死，刚好改了同一个文件的同一段，你一Pull下来冲突就来了。

这时候，Commit Skill就会大显身手。它检测到冲突后不会傻乎乎地报错，而是会读取冲突标记，结合你的改动意图和远程的改动内容，给出一个合并建议。你只需要确认一下合并方案，它就会提交合并结果，然后再Push。

这事儿要是搁以前，我得手动去比对文件，生怕合并错了把队友的代码给覆盖了。现在有了AI辅助，心理负担基本就没有了。

以前提到“重构”两个字，大概率dou是被坑过的。这几个风险加在一起——改错了、逻辑漏了、冲突了——正常人dou会选择不动。毕竟老话怎么说来着？“没坏别修，Neng跑就行。”

但现在不一样了。这套操作下来对我这种工作多年、经验丰富，业务又熟悉的人来说重构的心理负担基本就没有了。

我有600多行的工程规则Zuo后盾，有模块化的SkillZuo工具，还有Quality-gate帮我兜底。我想怎么改就怎么改，AI会帮我检查规范，帮我分析影响，帮我解决冲突。这感觉，就像是从骑自行车换上了开自动驾驶的跑车，虽然方向盘还在我手里但脚底下的油门踩得那叫一个顺畅。

说到底，Skill只是工具，工具好不好用，完全取决于你怎么配置它。光有Skill没有规则，AI不知道按什么标准来审查；光有规则没有Skill，规则写得再好也没有执行的载体。

这和写代码的道理是一样的：架构搭好了代码规范了系统才Neng稳。现在不dou是通过流水线去解决这个问题的吗？不用那么担心了吧。

所以回到Zui初的问题：有AI辅助，代码还需手动调整吗？

当然需要。但这时候的“手动调整”，不再是枯燥的搬砖，而是一种“审核”和“决策”。你依然是架构师，依然是掌控者，而AI，是你Zui听话、Zui高效的执行者。