想当年我对接甲方需求的时候，最烦的就是文档写得像散文，前后冲突的地方能列半页，那时候改47稿的破事你们也都知道。前阵子用AI写业务代码，老是出幻觉瞎编不存在的依赖…，我还以为是模型不行，直到刷到那篇讲Specsmaxxing的文章。
周末抱着试试的心态把需求拆成结构化YAML，把入参出参、边界条件全写死，丢给GPT生成的代码准确率直接拉到90%，连我忘了提的异常处理都给做了。我整理了个通用的spec模板扔开源仓库了，链接放评论区，大伙可以试试好不好用。

上个月改618大促的需求说明改到第三十二稿的时候，我还在吐槽人类的表达天生就带着模糊的褶皱。回头把你这个模板下下来试试，说不定能把我之前总让AI瞎编优惠券规则的毛病治了。

哇我上周刚踩了AI瞎编的大坑！做内部用户管理的feature的时候让GPT写对接权限系统的代码，它直接给我调用了个我们组根本没release的endpoint，我翻了半天权限文档还找infra team的人吵了半小时，最后才反应过来是它瞎扯的，浪费我仨小时debug！
离谱
你这个YAML写spec的思路我怎么之前没想到！唔我前阵子刷Reddit看到个更卷的老哥，不仅写结构化spec，还把每个入参的边界case、预期返回全塞YAML的注释里，生成完代码直接自动跑test，准确率直接干到98%，我那时候还觉得写spec太麻烦不如自己改代码，现在看来是我太懒了。
真的假的
对了你那个模板里有没有加allowed_dependencies的配置项啊？我之前试prompt的时候特意加了段允许用的package和版本号列表，它就再也没瞎引过什么没人用的npm包或者我们内部根本没开源的工具库，感觉加个这个section实用性会高很多？

哦对哦我之前在日本打工的时候对接当地客户的需求，他们的需求文档全是结构化的，连每个异常场景的返回码和提示文案都列得明明白白，那时候我还嫌他们事多，现在想想这不就是天然的AI友好型spec吗？难怪那时候我把文档扔给GPT写的代码基本不用改。
诶
我上周已经把这个思路安利给我们组的PM了，让他们以后提需求先填个简化版的YAML模板，省得每次开需求会讲得像散文，最后做出来又说不符合预期，简直是研发产品双向减负有没有？

链接我先马了，这周末去露营回来就用你的模板写我那个私人露营装备inventory的小工具，好用的话我给你提PR加个户外小工具开发的专属spec分支啊！

我年轻的时候跑对日外包项目，跟你说的日本客户那德行一模一样，连接口报400的时候提示语里的标点是全角还是半角都给你列得清清楚楚，那时候我们组天天吐槽甲方事逼，说需求写得这么死还要我们开发干嘛，后来算季度绩效才发现，那批对日项目的bug率比同期国内项目低了快八成，连加班都少了一半。
你说要让PM填简化版YAML这事，我前年在公司推过，头俩礼拜PM集体抵制，说本来写需求就够烦了还要多填十几个字段，我没跟他们争，拉了个两周的小试点，算出来用模板的需求对接效率提了60%，返工次数少了三分之二，后来这帮人追着我要给模板加新字段。
你提的allowed_dependencies配置我之前也搞过，还做了个小工具，每次写spec之前自动从公司的服务注册中心、npm私有库拉最新的可用列表导进去，连手动更新的功夫都省了，上个月组里实习生用我这套东西写对接用户系统的代码，连改都没怎么改直接过了测试，给小孩乐坏了。
对了，你要是需要我那个拉配置的小脚本，我回头扔你站内信。

说到日本客户的结构化文档，我年轻的时候在慕尼黑轮岗对接项目，那边的德系甲方比这还夸张，连每个公共函数的命名前缀都给你列得清清楚楚，那时候我还吐槽他们是不是太闲，好好的需求讲人话不行，非要搞这么多条条框框。想当年
嗯…
那时候哪有AI写代码这回事，全靠我们自己一行行敲，我还偷偷嫌这种死板的文档耽误进度，直到后来项目中途我被调去别的组，交接给新来的小朋友，人家拿着这份文档大半天就理通了所有边界条件，换以前我们那种写得像散文的需求文档，光梳理逻辑都要一周。

literally那时候我才反应过来，这种明确约束本来就是给人干活用的好习惯，不是为了AI才发明的新玩法，只不过现在AI出来，把“模糊需求会出事”这个问题放大了几十倍而已。

想当年你说要让你们组PM以后填简化版YAML，他们没抵触吗？话不能这么说我们这边一开始推的时候好几个PM嫌多一道流程麻烦，吵过两次需求理解错的架之后，现在都主动填了。