https://www.swiftmiss.fun/tags/agentic-engineering/Recent content in Agentic Engineering on 隔空想念Hugo -- gohugo.ioen© 2025, VanguardMon, 02 Mar 2026 00:00:00 +0000https://www.swiftmiss.fun/post/2026-03-02-how-to-write-a-good-spec-for-ai-agents/Mon, 02 Mar 2026 00:00:00 +0000https://www.swiftmiss.fun/post/2026-03-02-how-to-write-a-good-spec-for-ai-agents/如何给 AI 智能体写一份好的需求规格 本文最初发表于 Addy Osmani 的 [Elevate] Substack 通讯，经作者授权在此转载。 太长不看版：写一份清晰的规格文档，包含恰到好处的细节（可能涉及结构、风格、测试、边界等），既能引导 AI 又不会把它"淹没"。把大任务拆成小任务，而不是塞进一个巨大的提示词里。先用只读模式做规划，再执行，然后持续迭代。 “我听说了很多关于给 AI 智能体写好规格的说法，但一直没找到一个靠谱的框架。我可以写一份堪比 RFC 的规格文档，但到某个程度上下文太大，模型就崩了。” 很多开发者都有这种困扰。把一份巨大的规格一股脑丢给 AI 智能体是行不通的——上下文窗口的限制和模型的"注意力预算"会成为拦路虎。关键是要写聪明的规格：能清晰引导智能体，保持在实际可用的上下文大小范围内，并且能随项目演进。本指南从我使用 Claude Code、Gemini CLI 等编码智能体的经验中提炼出最佳实践，形成一套规格写作框架，让你的 AI 智能体保持专注和高效。 我们会讲五大原则，每个原则都以加粗的核心要点开头。 1. 从高层次愿景出发，让 AI 来补充细节 用一份简练的高层次规格启动项目，然后让 AI 把它扩展成详细计划。 不要一开始就过度设计，先写一个清晰的目标声明和几条核心需求。把它当作一份"产品简报"，让智能体基于此生成更详尽的规格。这样既发挥了 AI 擅长展开细节的优势，你又能把控方向。当然，如果你一开始就有非常具体的技术要求，那就直接写进去。 为什么这招管用： 基于大语言模型（LLM）的智能体在收到一个清晰的高层指令后，特别擅长补充细节，但它们需要一个明确的使命才不会跑偏。通过提供一个简短的大纲或目标描述，让 AI 生成一份完整的规格文档（比如 spec.md），你就创建了一个智能体可以持续参考的"锚点"。对于智能体来说，提前规划尤其重要：你可以先反复打磨计划，然后再交给智能体去写代码。这份规格就成了你和 AI 一起构建的第一个产出物。 实操方法： 在新的编码会话中，你可以这样提示： 你是一个 AI 软件工程师。为[项目 X]起草一份详细规格，涵盖目标、功能、约束条件和分步计划。 保持初始提示词的高层次，比如：“构建一个用户可以跟踪任务（待办清单）的 Web 应用，需要用户账户、数据库和简洁的 UI。” 智能体可能会回复一份结构化的规格草案：概述、功能清单、技术栈建议、数据模型等等。这份规格就成为你和智能体都能随时查阅的"唯一权威来源"。GitHub 的 AI 团队推动的规格驱动开发理念就是"规格成为共享的唯一权威来源……是随项目演进的、活的、可执行的产出物"。在写任何代码之前，先审查和完善 AI 的规格——确保它跟你的愿景一致，纠正任何"幻觉"或偏离目标的细节。 用计划模式来强制"先规划"： Claude Code 等工具提供了计划模式，限制智能体只做只读操作——它可以分析你的代码库并创建详细计划，但不会写任何代码，直到你准备好。这非常适合规划阶段：在 Claude Code 中启动计划模式（Shift+Tab），描述你想构建什么，让智能体在探索你现有代码的同时起草规格。让它通过向你提问来澄清模糊之处。让它从架构、最佳实践、安全风险和测试策略的角度审查计划。目标是把计划打磨到没有误解的余地。只有到那时，你才退出计划模式让智能体开始执行。这个工作流可以避免"规格还没站稳就急着生成代码"的常见陷阱。 把规格当作上下文来使用： 规格定稿后，保存为文件（比如 SPEC.https://www.swiftmiss.fun/post/2026-03-02-agentic-engineering/Mon, 02 Mar 2026 00:00:00 +0000https://www.swiftmiss.fun/post/2026-03-02-agentic-engineering/智能体工程：AI 辅助开发的正确打开方式 2026 年 2 月 4 日 一年前，Andrej Karpathy 创造了"vibe coding"（氛围编程）这个词，用来描述一种"放飞自我"的编程方式：你写个提示词，把键盘交给 AI，不看代码差异，它输出什么你就接受什么，遇到报错就把错误信息粘贴回去让 AI 再试。这个概念精准地捕捉到了一种真实存在的现象——用纯 AI 自动驾驶模式来快速搭建原型或最小可行产品。 问题是，“vibe coding” 已经变成了一个"万能标签"。人们用它来描述从周末小项目到严谨工程流程在内的一切——后者是指在人类监督下，AI 智能体负责具体实现的专业开发模式。这两者有本质区别，把它们混为一谈正在造成真正的混乱和损害。 Vibe coding 到底是什么 Vibe coding 的核心特征是跟着感觉走，不审查代码。你写提示词、接受输出、运行看效果。不行就把错误粘回去再试，一直反复提示。在这种模式下，人扮演的是"提示词 DJ"，而不是工程师。 这种方式在以下场景确实好用： 全新项目的 MVP、原型和黑客马拉松 demo。 你需要周日之前搞出个能跑的东西，代码质量无所谓。个人脚本和一次性工具。 你是唯一的用户，坏了就重新生成。学习和探索。 新手可以借助 AI 做出原本做不出的东西，通过 AI 的输出"照葫芦画瓢"来学习。创意头脑风暴。 故意让 AI 大量生成各种方案，看看它有什么思路，然后丢掉重来、认真构建。 如果 vibe coding 能让数百万原本不会写代码的人拥有开发自定义软件的能力，那这确实是一个了不起的进步。这种技术在工具箱里有它的一席之地。 但它的失败模式已经被充分记录了。套路总是一样的：demo 效果很棒，然后现实就来了。当你想修改、扩展或加固安全性时，就会发现没人真正理解这些代码到底在干什么。正如一位工程师说的：“这不是工程，这是在碰运气。” 我们需要一个更好的术语来描述专业版本 事情是这样的：很多经验丰富的工程师现在正从 AI 中获得巨大的生产力提升——2 倍、5 倍、甚至更多——同时保持着代码质量。但他们的工作方式和 vibe coding 完全不同。他们在写提示词之前会先写需求规格文档，会逐行审查每一个代码差异（diff），会运行测试套件。他们把 AI 当成一个速度很快但不太靠谱的初级开发者，需要持续监督。我个人一直喜欢"AI 辅助工程"（AI-assisted engineering）这个说法，也讨论过它如何描述了人类始终保持参与的那一端。 Simon Willison（我非常欣赏他的工作）提出了"vibe engineering"（氛围工程）——他想保留"vibe"这个词，同时加上"engineering"来传递专业纪律的信号。但在观察了社区围绕这个话题争论数月之后，我觉得"vibe"这个词包袱太重了。它天然传达出随意感。当你告诉 CTO 你在"vibe engineering"公司的支付系统时，你能看到他脸上的担忧。 Andrej Karpathy 本周提出了"agentic engineering"（智能体工程），我觉得这个叫法很不错。