说实话，这事儿挺让人抓狂的。你有没有过这种经历：本来只是想让AI帮你写个简单的“用户列表导出”功Neng，结果它反手给你整了一套包含Excel、CSV、PDF甚至还Neng自动发邮件的完整系统？kan着屏幕上那几百行凭空冒出来的代码，你心里是不是五味杂陈？这哪里是辅助编程，简直就是请了个“过度热情”的实习生，好心办坏事。

这就是当下hen多开发者面临的窘境。我们管这叫“Vibe Coding”——你给AI一句模棱两可的话，它还你一堆凭运气的代码。有时候灵光一现，有时候灾难现场。特别是不管是Cursor还是Trae，亦或是大家dou在用的Claude，效率确实提上去了但血压也跟着上来了。Zui怕什么？Zui怕它自作主张。你让它修个Bug，它敢把整个模块重写；你让它加个登录，它敢给你整出OAuth、短信验证甚至人脸识别。

改完之后你kan着满屏的红绿Diff，Code Reviewdou无从下手。这哪里是写代码，这简直是在玩扫雷，踩中哪个雷全凭运气。

咱们得承认，光靠“聊”是聊不出高质量代码的。迭代这么快，不是工具geng先进了而是我们一直没找到一套靠谱的解决方案。到Zui后还是一人一个编程习惯，全凭感觉在瞎折腾。对于正式项目、多人协作、长期维护的系统来说这种“聊天式”的编程模式显然是不够的。

Zui近，GitHub发布了一个叫SpecKit的开源工具包，这玩意儿一亮相就迅速斩获了18.5K Star，风头无两。它似乎真的摸到了AI编程的痛点，试图彻底改变现在的游戏规则。SpecKit是专为与AI编程代理进行Spec驱动开发设计的，里面包含了CLI工具、模板和引导提示。不管是配合GitHub Copilot还是Claude，它douNeng把那些临时的、碎片化的提示词，转换成结构化的、可验证的开发工作流。

这其中的核心思想，其实非常朴素，甚至有点返璞归真的味道：不让AI直接写代码，而是先让它写规范。

这就是OpenSpec要解决的问题。它的逻辑hen简单：规范写清楚，你确认了AI再动手。它敢乱加功Neng？规范里没有，它就不该写。这就好比Git的main分支和feature分支——规范是稳定版，变geng是提案。你得先在提案里把事情说清楚，通过了才Neng动手。

咱们来想象一个具体的场景：你要给后台管理系统加一个“按角色筛选用户”的功Neng。

在传统的Zuo法里你可Neng会直接对AI说：“帮我给用户列表加个角色筛选。”然后AI就开始噼里啪啦地生成代码了。但在OpenSpec的Zuo法里你告诉AI：“给用户列表加按角色筛选”，AI不写代码，它先建文件。

它会生成一个类似这样的目录结构：

changes/add-role-filter/
├── proposal.md   # 为什么要加、加在哪
├── tasks.md      # 要干哪几件事
└── specs/user-list/spec.md  # 具体怎么筛

你kan，这时候屏幕上没有一行业务代码，只有文档。AI在`proposal.md`里写清楚为什么要加这个功Neng，业务价值是什么打算加在哪个模块。这就逼着AI先思考“为什么Zuo”，而不是急着去想“怎么Zuo”。

这一步至关重要。打开`proposal.md`kan一眼。太复杂？删掉多余功Neng。太简单？补充细节。确认无误后你再告诉AI：“Ke以干了”。

这就是你作为开发者的掌控权。以前是AI写完了你再去挑刺，现在是AI干活前先过问你。这种角色的转变，Neng让你心里踏实hen多。就像盖房子，先kan图纸，图纸没问题了再允许工人动工。要是图纸里画了个游泳池，而你只想要个水槽，这时候改图纸还来得及，总比等游泳池挖好了再填坑强吧？

审批通过后AI会按照`tasks.md`里的内容逐条实现。这个文件里列得清清楚楚：要修改哪个路由，要geng新哪个数据库查询，前端要加什么组件。

AI严格按照`tasks.md`逐条实现。不会多写一行多余代码。你Ke以随时kan进度——Zuo了几条，还剩几条。这种可视化的进度条，比kan着黑屏里滚动的日志要安心得多。它就像一个听话的执行者，指哪打哪，绝不乱跑。

代码合入后执行归档。`changes/`里的内容合并到`specs/`，成为新规范。下次改代码，AI就知道现状是什么不会再重复造轮子。

这一步其实hen多人容易忽略，但它是长期维护的关键。下次再加个CSV导出，你知道要从`specs/`里改，而不是在代码里瞎塞。这就好比每次Zuo完项目dou要写结案报告，把经验教训留下来。新AI加入项目，读一遍`specs/`目录，秒懂系统全貌。不用重新“聊天灌上下文”，不用费劲巴力地解释历史背景。这就是所谓的“可复用”。

咱们来对比一下。传统Zuo法是：开发者说“帮我写个导出按钮”，AI生成200行代码，包含Excel、CSV、PDF三种格式，还自带邮件发送。开发者崩溃：“我只想要Excel啊...” AI说：“好的，重新生成...” 然后又是几百行代码。

而OpenSpecZuo法呢？它把“写代码”这个动作延后了把“思考”和“确认”提前了。这带来的好处是显而易见的。

是可审查性。 Code Review不再是kan几百行晦涩难懂的代码diff，而是kan规范变化。规范对了代码大概率对。 reviewing文档总比reviewing代码要容易得多，也快得多。Ru果文档里写着“只导出Excel”，而代码里出现了PDF相关的类库，那肯定有问题，一眼就Nengkan出来。

然后是可追溯性。 每个功Nengdou有对应的规范文件。谁写的？什么时候？为什么？全在Git历史里。这就好比每个产品dou有出生证明，以后出了问题，查档案就行。不用去猜这段代码是哪个天才半夜喝醉了写出来的。

虽然我们今天聊的是GitHub的SpecKit，或者是大家熟知的Trae、字节出品的AI编程助手，但其实工具本身并不是Zui重要的。TraeZui近推出了自定义智Neng体的新功Neng，Claude有了geng长的上下文窗口，这些dou只是手段。

真正重要的是我们要改变那种“把AI当神灯”的心态。别指望搓一搓手，许个愿，代码就自动变出来了。AIgeng像是一个需要明确指令的超级实习生。它不缺Neng力，缺的是方向。

对于非STEM出身的普通用户，学习使用具体的AI应用软件，如ChatGPT、Midjourney等，可Neng觉得只要会说话就行。但对于编程这种严谨的工程活动，提示词的重要性怎么强调dou不为过。尤其是一个好的智Neng体提示词就直接决定了产出的质量。

OpenSpec其实就是一种高级的、结构化的提示词管理方式。它把零散的对话变成了工程化的文档。

咱们写代码的，dou知道“愉悦、不拧巴”的状态有多难得。人玩游戏hen容易投入，为什么？有目标，有规则，还有及时反馈。编程也一样。Ru果AI总是给你惊喜，那你肯定会焦虑，会拧巴。但Ru果AI严格按照你定的规矩办事，每一步dou在你的预料之中，那种掌控感带来的愉悦，是无可替代的。

下次我们再来聊聊如何在现有项目中具体配置Claude来配合这套工作流。不过在此之前，建议大家先试着把“先写文档”这个习惯养起来。别一上来就撸代码，哪怕是用AI撸也不行。

毕竟我们要Zuo的不是AI时代的数字难民，而是要成为拓荒者与原住民。选择适合自己的学习方法和路径，结合理论学习和实践操作，是快速掌握AI辅助编程的关键。别让AI瞎写，你的代码库，得听你的。