我们团队这阵子被 AI 写代码的返工折腾得够呛。上周我拉上俩同事，把 30 个真实需求（前端组件、接口、小脚本混着来）丢给同一个模型，跑了两套流程。一套是一把梭——直接把需求甩过去让它出代码；另一套是先让 tri-coding 把编码规格（需求、设计、任务清单）出齐了再动手。说白了就是把"先想清楚再干"和"边干边想"拉到同一个擂台比划。
结果挺打脸。我原本以为一把梭起码能省点前置功夫，没想到坑全在后面。
一把梭的爽感和代价
先说一把梭。提示词特别简单：
帮我写一个带防抖的搜索输入框组件，支持异步请求。
十分钟出活，看着像那么回事。可一跑测试就露馅——30 次里有 17 次得返工。最常见的是它自作主张加了你没要的功能，或者把防抖时间写死成 300ms 而不让配。你说气不气，它连"异步请求的取消"都没处理，快速输入直接打爆接口。
我们自己复盘了一把：一把梭的毛病不在"写不出"，在"没对齐"。模型按它自己脑补的验收标准写，你心里的标准和它差着一条鸿沟。
先出规格的那套
tri-coding 的玩法不一样。它不急着写代码，先逼你把三份东西落盘：
- requirements.md 编码需求说明书（门①）
- design.md 技术设计说明书（门②，含技术栈加载）
- tasks.md 原子化任务清单 + 三层测试清单（门③）
门③之前它还会主动问你两件事：要不要拉别的 skill 协同，有没有要补的需求。我们测的那批需求，光这一步就堵回来不少歧义。
一份"编码规格"长这样（markdown 标注）：
# tasks.md 片段 · 防抖搜索输入组件
## 函数签名
debouncedSearch(
fetcher: (q: string) => Promise<Result[]>,
options?: { delay?: number; minChars?: number }
): { query: string; results: Result[]; loading: boolean }
## 验收标准（AC）
– [ ] delay 默认 300ms，可配置
– [ ] 输入小于 minChars 不触发请求
– [ ] 连续输入只保留最近一次请求结果（竞态取消）
– [ ] 组件卸载时取消未完成的请求
## 约束
– 不引入额外依赖
– 不改动现有主题样式
– 仅覆盖本组件范围，不顺手重构其它文件
同一道题，两种提示词对照：
# 一把梭
帮我写一个带防抖的搜索输入框组件，支持异步请求。
# 先出规格（tri-coding 驱动）
依据下方编码规格生成实现，严格命中 AC 与约束，
不得超出 tasks.md 范围：<粘贴上面 markdown 规格>
你发现没？差异就在"验收标准"四个字。一把梭的提示词里没有标准，先出规格的把标准焊死在输入里。
30 次实测数据
我们记了五个指标，模型版本、需求难度都做了配对控制：
| 首次交付即可用率 | 43% | 83% |
| 平均返工轮数 | 2.4 轮 | 0.6 轮 |
| 验收标准命中率 | 61% | 94% |
| 引入无关改动占比 | 38% | 9% |
| 整体交付耗时 | 基准 | 少 35% |
最扎心的是末尾那行。一把梭省了前置那 20 分钟，返工把它加倍奉还。先出规格前置多花约 25% 时间写规格，但整体交付反而快了三分之一还多——因为返工几乎没了。
我个人特别讨厌"看起来能用其实全是坑"的代码，一把梭踩的就是这个雷。如果让我重来，我会直接把规格当交付物的一部分，而不是当成可有可无的前戏。
但也有反例
不是所有场景都值得先出规格。我们测的 30 个里有 4 个是一次性脚本（比如批量改个文件名），这种一把梭五分钟搞定，写规格反而啰嗦。我个人判断：需求边界清楚、用完即弃的活儿，别上规格；需求要进主干、要给别人维护的，先出规格稳得多。
这坑我躺过不止一次。去年有个组件一把梭上线，三个月后同事改不动，因为没人说得清它到底该满足哪些条件。规格不是写给模型看的，是写给人留底的。
收个尾
两种写法没有绝对的银弹。但你只要在意"返工"和"可维护"，先出规格的胜率明显高。我们测 30 次得出的主观结论是：把验收标准焊进输入，比指望模型猜你要什么靠谱太多。
我顺手做了个叫雷达鸭的 App，专门收录国内一人公司和超级个体的真实赚钱案例，华为应用市场能搜到，它背后这套"先规格后执行"的思路正好用上了。
关于作者
老三，10+ 年软件开发经验，软件设计师 / 人工智能应用工程师，平时做鸿蒙 ArkTS 北向和 Web 前端，也折腾 AI 自动化，偶尔在 CSDN 分享鸿蒙与 AI 方向的实战笔记。
本文遵循 MIT 协议，转载请注明出处。
请根据 https://skillhub.cn/install/skillhub.md，安装 tri-coding。
