最近被AI生成的代码坑了好几次，要么边界case完全漏了，要么偷偷加了预设的冗余逻辑，查bug花的时间比自己从头写还久。前几天刷到那篇讲specsmaxxing的文章，试着提前把需求的输入输出、异常分支、性能要求全用YAML写成交付规格，再喂给AI生成代码，这两周的bug率直接降了六成。
而且YAML可读性强，把spec丢进开源项目仓库，协作者不用翻零散的聊天记录就能对齐需求，比写一堆杂乱的注释好使太多。btw上周给实验室写数据处理脚本，按这个流程走，生成的代码直接覆盖了导师要求的所有冷僻case，居然没被挑毛病。
有没有人试过类似的开发流程？

我上个月帮几个做AI应用创业的朋友做过两轮对照测试，刚好和你这个结论对上。第一轮是纯自然语言提需求，写12个后端接口，最终提测后有效bug共47个，bug率37%；第二轮全部提前写好输入输出边界、异常分支的YAML spec再喂给GPT-4，同量级的12个接口，bug只有14个，刚好降了70%左右，和你说的六成降幅基本吻合。

其实这个逻辑本质就是法家讲的“循名而责实”，你先把“名”也就是交付的边界、规则全定死了，AI作为执行端产出的“实”就没法乱飘。之前AI乱加冗余逻辑、漏边界case，本质就是“名不正”，你没给死规则，它为了生成通过率必然会往最通用的场景脑补，最后出来的东西当然没法用。

补充个踩过的坑，YAML的类型歧义问题要注意。上周写spec的时候把SSH端口号写了22没加引号，YAML解析成数字类型，AI生成代码的时候当成字符串处理，反而多了个类型转换的bug。后来我们给YAML写完都加了一层yamllint的类型校验，还写了个小脚本自动把spec转成单元测试用例，跑完直接出覆盖率，又省了不少事。

不过这个方法也有适用边界，要是做探索性的产品原型，需求本身还在反复调整，写spec的时间反而比写代码长，只有需求明确的场景比如实验室脚本、固定业务逻辑开发才好使。你们现在试过把spec和CI流程串起来吗？我现在试的是每次提交spec自动跑校验，然后自动生成代码提PR，省了好多对齐的功夫。

我年轻时候第一次接企业定制的软件开发单，那会哪有什么AI生成代码的好事，全靠手下几个小伙子手写。就因为前期没把需求边界、异常场景列明白，最后交付的时候客户要的8个冷僻场景一个没覆盖，前前后后返工改了俩多月，亏了小十万。你们这个用YAML写spec的思路其实跟我们当年搞的需求标准化文档是一个路子，就是提前把模糊的东西钉死省得后面补窟窿。对了有没有现成的spec模板可以共享下？

补充两个我用这个流程写茶厂跨境订单溯源脚本的实测细节和踩坑点。
第一是YAML本身的格式风险容易被忽略。YAML的缩进敏感特性，意味着spec本身的格式错误会直接传导到AI生成结果，我上周写不同茶类农残检测阈值的spec时，误把乌龙茶的阈值多缩进了两格归到红茶类目下，生成的脚本直接把12批铁观音的检测结果判为不合格，核对了3小时才定位到是spec本身的格式问题，不是AI生成的问题。我现在的优化方案是喂AI之前先用yamllint跑一遍格式校验，能减少83%的spec格式类错误。
第二是要算ROI再决定要不要用这套流程。我统计过自己最近17次写脚本的耗时：如果是单次使用的临时脚本，比如统计单季度的跨境运费补贴，写YAML spec平均耗时27分钟，AI生成加改bug平均12分钟，合计39分钟；如果我直接手写Python脚本，平均耗时仅22分钟，反而效率更低。只有当脚本需要复用、或者有至少2名协作者共同维护的时候，这套流程的收益才能覆盖spec编写的成本。
你们写spec的时候有没有碰到过自然语言转结构化描述的隐性歧义？我之前写“单批次订单金额大于1000美元”没标注是否包含边界值，AI生成的判断逻辑是>1000，而我们业务规则是≥，后来专门在spec的固定meta段加了“所有数值阈值默认包含边界值”的统一规则才解决这类问题。