夜雨聆风昨晚 11点左右，我收到一条微信消息：
“赵老师您好，我是今天下午腾讯云架构师沙龙的听众方**，目前是成都大学的学生。您讲的从 Prompt 到 Spec 的 SDD 方法论特别有启发，正好解决了我之前用 AI 写代码时需求反复、输出不稳定的痛点。我之后也想往 AI 工程化方向发展，现在正在做一个园林相关的小项目练手，冒昧加您微信，之后项目上遇到具体的 SDD 落地问题想向您请教，打扰您了！”
前言
上周六我参加了腾讯云架构师成都同盟组织的主题为《大模型到AI同事：Agent时代的工程化落地》的线下社群活动，并且分享了我的个人主题《从 Prompt 到 Spec：AI Agent 时代的研发工程化实践》，活动结束后被很多朋友围住，继续探讨意犹未尽的内容，上面这位方同学，就是其中一位，当我看到这则消息时，有那么一瞬间，我感觉我也回到了18岁—— 那个对技术充满好奇，总想把脑子里的想法亲手捏出来的年纪。哈哈哈～开个玩笑，进入正题...
为什么 AI 让写代码重新变得 “好玩”
这两年聊 AI 编程，大家最容易感受到的是 “爽感”：一句话生成页面，几句话改完功能，一周的想法一晚就能做出雏形。第一次把 AI 用顺手时，我真切感受到软件开发的门槛在被改写 —— 那些曾卡在 “不会写代码” 的想法，终于有了先跑起来的机会。
这种 Vibe Coding 的方式，像把脑子里的东西直接掏出来：不用先抠结构、摆姿势，说个大概，AI 就动手；不满意补两句，它就接着改。就像面前坐了个不嫌烦、手速快的搭子，最打动我的不是快，而是创造欲被立刻接住的感觉。
做技术久了，人难免被排期、需求、技术债磨得务实，那种 “刚冒念头就能捏出样子” 的创造感，早就不常见了。AI 把这种感觉带了回来，让我重新觉得，写软件这件事，很好玩。
但顺滑的背后，藏着容易忽略的问题
AI 最迷人的地方，从来不止是帮程序员写代码更快 —— 它让更多原本够不到 “实现” 的人，能把想法做出来。比如看到回转寿司想到 “任务流时间管理”，以前这种点子大概率只停在脑子里，现在却能和 AI 聊出原型，用极低成本验证。
可越顺滑，越容易产生 “AI 懂我” 的错觉。一开始，你说需求它八九不离十，补一句它就顺着改，仿佛不用查文档、开会议，靠 “默契” 就能搞定。但这种状态，只在问题简单时成立。
项目稍复杂、进入真实业务协作，问题就暴露了：AI 不是不聪明，只是没真正 “理解” 你，只是接住了当下的上下文。上下文一长就飘，需求一变就忘，多人协作口径乱，模块拆分边界糊，之前定的约束没沉淀，后面等于白说。到最后，前几轮觉得像神，后几轮开始怀疑人生。
我从来不觉得 “模型更强、上下文更长，这些问题就会消失”。研发里真正的麻烦，大多不是 “生成能力” 的问题，而是 “约束能力” 的问题：边界有没有讲清？定好的规则有没有固定？不同人、不同阶段，是不是用同一套语义？没做好这些，AI 越能写，反而越容易偏。
从 “写 Prompt” 到 “定意图”，才是核心
这也是我在实际项目中一直使用 SDD的原因。这套思路讲的是规范、约束、结构化表达、验收标准，听起来不如新模型、新 Agent 那么 “性感”，但恰恰击中了真问题。
企业研发最怕的从来不是写得慢，而是 “各说各话”：以为大家聊的是一件事，其实不是；以为系统按原则生长，其实早偏了；以为 AI 在提效，其实是在加速制造未来的麻烦。现在很多团队不是不会用 AI、没热情，而是都在往前冲，却没有稳定的 “准星”—— 每个人有自己的理解，每次对话有自己的上下文，最后局部最优，拼起来却一塌糊涂。
所以我觉得AI 时代最值钱的不是 “会写 Prompt”，而是 “会定义意图”。把事情讲清楚，不是面面俱到，而是边界、目标、约束、验收要清晰。只有意图稳定了，后面的落地才会稳。
这次分享主题叫《从 Prompt 到 Spec》，核心就一句话：别只顾着让 AI 动起来，先让 “意图” 稳定下来。很多人上来就问 “Agent 能不能自动拆任务、改代码、提 PR”，这些固然重要，但如果目标没对齐，自动化越彻底，偏差只会越大。
现在看 AI 编程工具，我不再只看 “能做什么”，而是看它能不能既快又稳 —— 不仅帮我产代码，还帮我沉淀意图。只有两者都做到，它才有可能真正走进企业研发的主流程。
SDD 不是银弹，只是不同阶段的选择
当然，SDD 不是万金油。写好规范本身就不轻松，不是把需求换个格式，而是要想清楚：哪些必须定死？哪些能留给出发挥？哪些在范围里？哪些明确不做？什么叫 “做完了”？
很多团队习惯边开发边补这些问题，AI 出现后，这种做法的代价变高了 —— 以前消耗的是人，现在消耗的是整个协作系统的稳定性。但这也不意味着所有场景都要搞重流程：做个人项目、黑客松作品、验证小想法，完全可以先 “vibe” 起来，先跑起来再说，硬拉流程反而会丢了手感。
我的理解是：探索阶段，不妨随性一点，解决 “敢不敢开始” 的问题；进入协作阶段，就得规范一点，解决 “能不能持续” 的问题。两者不对立，只是项目不同阶段的不同姿势。
未来：代码“重要”，但 “定义” 更重要
活动结束后，很多小伙伴找我聊：工具怎么选？团队怎么推？AI 写代码越写越乱怎么办？工程师是不是只要 “提需求” 就够了？这些问题没有标准答案，但我越来越确定：未来的软件研发，会越来越偏向 “先定义意图，再组织实现”。
代码、技术细节、架构能力依然重要，但人的价值，会更多体现在这些地方：能不能把模糊的问题讲清楚？能不能识别不能丢的约束？能不能把团队、工具、系统拉到同一张图上？
AI 不是来帮我们偷懒的，它是逼着我们重新回答：软件工程里，什么才是真正不该外包给机器的？我觉得答案不是 “写代码”，而是判断、定义、取舍，是对边界的敏感，是对结果的负责。
那位同学的消息打动我，不是因为他夸了分享，而是从他的真诚里，看到了一个人认真接近新世界的样子 —— 就像当年刚学技术的自己。AI 最好的地方，或许不是让我们少干活，而是让我们重新认真起来：认真想需求到底是什么，协作该怎么发生，软件该怎么被构建。
最后想说
特别感谢腾讯云架构师成都同盟的组织与付出才有这样精彩的活动，感谢龙哥的引荐、感谢梁老师、王老师的真诚交流，也感谢现场每一位认真聆听、热情提问的朋友。你们的投入，让这场活动变得格外温暖而有力量。
AI 浪潮再汹涌，真正决定我们能走多远的，永远是初心、连接与沉淀。未来，我也希望能更多参加社区活动，把真实项目里的思考、踩过的坑、阶段性的感悟，毫无保留地分享出来。
愿我们都能在技术的路上，保持热爱，彼此同行。
最后的最后
如果说 AI 让我重新回到了 18 岁，不是因为它让我变年轻，而是因为它让我再次认真思考：技术会带我们去哪里，而我们该成为什么样的工程师。
👇👇👇👇欢迎大家加入成都同盟👇👇👇👇
