用 CodeArts 码道做开发：生成、人工审、脚本验三步走

AI 辅助写代码最容易踩的坑，不是模型写得慢，而是人把第一版输出直接当成了成品。模型擅长一次给出一大段看起来能跑的代码，却不擅长保证这段代码的逻辑真正成立。一次真实的开发过程里，最管用的办法是把流程拆成三步：让模型生成、让人审查、再用脚本校验。少了中间任何一步，后面都要花更多时间返工。

一、生成：需求要写到“可验证”为止

让模型生成之前，先把需求写成模型能对齐、事后能验证的样子。含糊的需求只会换来含糊的代码，返工的起点就在这里。

一个能用的需求描述，通常包含四样东西：

1. 输入是什么：用户点什么、选什么，数据从哪来
2. 输出是什么：页面上出现什么、格式是什么
3. 约束是什么：不能用什么、必须满足什么规则
4. 怎么算对：列出 3–5 条事后能一条条打勾的验收点

举个例子。不要只写“生成一个磁盘诊断的决策模块”，要写成：

症状：磁盘空间不足。
形式：问诊式决策树，用户回答是/否问题，逐步走向一个根因结论。
约束：决策树必须是纯树形，不能出现回边；每个结论节点都要有对应的处置命令。
验收：问题节点与结论节点的数量可数；每条从根到结论的路径都能走通；结论里的命令可以直接复制执行。

第四条“怎么算对”最关键。它不是写给模型看的客套话，而是第二步人工审、第三步脚本验的依据。需求里没有验收点，审查的时候就没有标准，只能凭感觉说“看着还行”。

二、人工审：先审逻辑，再看代码细节

模型交出第一版之后，不要先跑、不要先看代码风格，先审逻辑。逻辑错了，代码跑得再顺也是错的。

人工审查有一张固定的检查单，按顺序过：

1. 分类对不对：每个结论是不是真的属于它挂的那个类别。类别错了，后面整个分支的处置方向都是错的。
2. 结构对不对：决策树是不是纯树形，有没有分支绕回去、有没有走到死胡同的路径。
3. 覆盖全不全：常见情况是不是都有对应的结论，有没有明显缺了一块。
4. 命令能不能用：结论里给的命令，是不是真的能复制到服务器上执行，有没有写错参数、有没有假设了不存在的文件。

这一步曾经真实地拦住过两个问题：一版决策模块里，systemd journal 被错误地归进了日志类结论；另一个分支出现了回边、不是纯树形。这两个问题光看代码、光跑演示都不容易发现，因为页面照样能点、结论照样能出——错的是结论本身的归属和路径的合法性。只有按检查单逐项对，才拦得住。

审出问题之后，不要自己直接改代码了事。把问题原样告诉模型，让它改到下一版，再重新过一遍检查单。自己随手改，看似省了一步，实际上把“模型输出”和“人工修改”混在了一起，下一版再出问题，就分不清是谁的责任了。正确的做法是：追问修正，让模型对最终版本负责，人只负责验收。

三、脚本验：把检查单变成能重复跑的东西

人工审过一遍还不够。人的检查是一次性的，下次模型再改一版，还得重新审一遍。把检查单里能量化的部分写成脚本，以后每次改版跑一次脚本，几秒钟就知道有没有退化。

脚本不用写得很重，抓住三类校验就够了：

// 伪代码：决策树校验脚本的核心思路
// 1. 节点数校验：问题节点、结论节点数量与需求一致
// 2. 引用完整性：每个分支指向的节点都存在，没有悬空引用
// 3. 路径模拟：从根节点出发，枚举所有回答组合，确认每条路径
//    都能到达一个结论节点，没有死胡同、没有回边

• 节点数校验防的是“改版改丢了东西”：上一版 7 个结论，这一版只剩 6 个，脚本立刻报警。
• 引用完整性防的是“改版改断了链接”：分支指向了一个不存在的节点，页面上点到那一步就卡住。
• 路径模拟防的是“改版改坏了结构”：回边、死胡同这类问题，靠眼睛看几十个节点很容易漏，靠枚举一眼就能看出来。

这三类校验跑通，才算这一版真正通过。人工审 + 脚本验的组合，意义在于分工：人负责判断“分类对不对”这种需要理解的问题，脚本负责“数量对不对、链接断没断、路径通不通”这种枯燥但不能错的问题。

四、什么值得留下来：过程证明

开发过程里还有一件容易被低估的事：把过程本身留下来。模型生成了几版、人工审出了什么问题、追问修正改了什么、脚本校验跑了什么结果，这些记录在当时看起来是额外负担，事后却是最有用的材料。

• 评审的时候，过程记录能证明代码不是一次性碰运气碰出来的；
• 复盘的时候，过程记录能说清哪一步拦住了问题、哪一步还可以再提前；
• 下一次再做类似开发的时候，过程记录就是现成的流程模板。

具体留什么，不用复杂：每一版的生成时间、审查发现的问题清单、追问修正后的版本号、脚本校验的通过结果，四样就够了。存在代码仓的说明文档里，和代码放在一起，别只留在聊天记录里——聊天记录翻起来最费劲，丢起来也最容易。

五、排查清单（收藏版）

1. 生成前先写验收点：输入、输出、约束、怎么算对，四样齐了再让模型动手。
2. 人工审先审逻辑：分类、结构、覆盖、命令，按顺序过，不要先看代码风格。
3. 审出问题让模型改：不要自己随手改完混过去，改完重新过检查单。
4. 检查单能量化的写成脚本：节点数、引用完整性、路径模拟，每次改版跑一次。
5. 过程记录和代码放一起：版本号、问题清单、校验结果，事后复盘和评审都靠它。

AI 辅助开发真正的提速，不在生成那一下，而在生成之后的那两步：人把逻辑审住，脚本把退化拦住。生成可以交给模型，验收不能交给感觉。