https://www.swiftmiss.fun/tags/ai/Recent content in AI 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"（智能体工程），我觉得这个叫法很不错。https://www.swiftmiss.fun/post/2026-02-19-the-craft-of-the-instruction/Thu, 19 Feb 2026 00:00:00 +0000https://www.swiftmiss.fun/post/2026-02-19-the-craft-of-the-instruction/指令的技艺 先说句实话。我上个月写的那篇文章，是用 Claude 一起完成的。这篇也一样。注意，不是让 Claude 替我写，而是和 Claude 一起写——这两个词的差别，恰好就是我想聊的事情。 这两篇文章都用到了"指令"——我自己写的、还在不断调整的一套规则。写这些指令的过程挺有意思：我得回头看自己过去写过的东西，搞清楚"我写作时到底有哪些习惯"。比如句子长短的节奏感、时间线上跳来跳去的手法、还有在大概念和小细节之间来回切换的方式。指令就像一份说明书，告诉 Claude"我希望文章组织成什么样子"。想法和素材是我的——来自我的生活经验和专业积累。为了这篇文章，我们前前后后改了十一版才定稿。大部分句子我都重新写过，但也不是每句都改。 这里面真正厉害的，不是 AI 吐出来的那些字，而是指令本身——那份你给 AI 的"操作手册"。 / 1977 年，有位叫 Christopher Alexander 的建筑师出了一本书叫《建筑模式语言》。书里列了 253 种"模式"——从一整片区域该怎么规划，到一个门把手该怎么安，都有。每种模式说的是同一件事：这里有个反复出现的问题，这是解决它的核心思路。比如"模式 159：每个房间要有两面墙有窗户"、“模式 88：街头咖啡馆”、“模式 252：聚光灯效果”。这些模式很具体、经过验证、有章可循。它们给你的是一套体系。 但 Alexander 真正感兴趣的不是这套体系本身。他在乎的是他说的"无名的品质"——一种说不清道不明的东西。当你把模式用好了，这种品质就会自然出现。但它没法被还原成逻辑或公式。他试了一个又一个词想把它说明白，没一个到位。这东西你只能感受到，说不出来。 打个比方：一道菜的食谱你可以写得很详细，但"好不好吃"这件事，不在食谱里。 我在宾夕法尼亚大学读的就是这类方向——建筑历史和理论。整天琢磨"设计理念怎么变成建筑，建筑里的生活又是怎么回事"之间的关系。我的毕业论文研究了一个很有意思的现象：三本经典的城市规划著作，分析的是同一座城市，却得出了三种完全不同的结论——因为每本书对"什么才是自然的"有不同的假设。你带进问题里的那个底层假设，会决定你后面看到的一切。 这种"体系很重要，但体系之外还有更重要的东西"的张力，一直跟着我。模式是骨架，模式来自经验的提炼。但让一个空间——或者任何人造的东西——真正有生命力的那一点什么，是模式促成的，却不在模式里面。 二十年后，我在一个完全不同的领域发现了同样的道理——就在我们写给 AI 的那些指令当中。 / 我以前写了很多东西。成堆的文章，可能没几个人读过。但那些写作磨出了一些东西——我把零散想法编织到一起的能力、我写长句子的感觉、还有那种"这句话到位了"的直觉。 后来生活把我淹没了。做了大约八年建筑设计，最近十来年又转行做产品设计，还生了两个娃。日常基本上就是在公司里扮演各种角色、给孩子做 K-pop 风格的发型、花大把时间跟工程师聊技术细节（然后想办法翻译成用户能理解的东西）、把营养餐端上桌然后看着它被嫌弃……在这一地鸡毛中间，我脑子里还是有些想法，很想好好用文字表达出来。我怀念以前在图书馆里、面对一堆书安安静静写文章的时光。但那种时间早就没了。写作这件事，基本上被搁置了。 于是我做了个实验。我找出自己以前写得好的文章——那些我还有时间精雕细琢时写的东西——喂给了 Claude。不是让它帮我写新文章，而是让它分析：我的写作到底有哪些特征？这是我当时写的提示词： 我希望你看看我写的这些文章，分析一下我用了哪些写作手法，然后为这个项目创建一套写作指令。我之后要写好几篇文章，希望它们读起来像我写的，用到我在这些旧文章中展现过的技巧。 Claude 找出了什么呢？我喜欢把句子写得长短不一。（大惊小怪对吧？）我喜欢在时间线上大幅跳跃——前脚还在聊四万年前的洞穴壁画，后脚就跳到了当代韩国装置艺术家梁慧圭的作品。我用"/“来分隔段落而不是小标题。我习惯把列表嵌在正文里而不是用圆点列出来。还有那些长破折号——在工作中，它总被同事吐槽"别这么写”，但在我自己的文章里，它反倒成了一种风格标签。 这些发现加在一起，就成了一套专属于我的"写作配方"。 为什么我说它就像 Alexander 的"模式语言"？因为这些配方确实符合他的描述：一组针对"怎么表达"这个老问题的、反复验证过的解决方案。每一条都够具体，用起来有方向感；又够灵活，可以组合出无限变化。不是固定模板，不是僵化公式，而是一种"语言"——你用它来构建作品，哪怕不是你一个人在写，出来的东西依然带你的味道。 这种"把直觉变成明确指令"的转变，在设计圈子里越来越多人在经历。UX Collective 上有一篇 Paz Perez 写的关于提示词的文章，说得很好：提示词不是什么"哄 AI 听话的小技巧"，而是设计师表达意图的新方式。她说"有效的沟通，跟人还是跟机器，都得看上下文"。她说的不只是"怎么把提示词格式写对"，而是一件更深层的事：我们平时靠直觉、判断力和品味做事，这些东西一直藏在心里，现在得想办法把它说出来。 / 这个过程改变了一些东西。不是说 Claude 现在"写得跟我一模一样"——没那回事。而是说，通过这个过程，我第一次真正看清了自己的写作手法。我能看到自己做了什么动作，能给每个动作起个名字。 Alexander 觉得，不应该只有建筑师才懂这些"模式"，普通人也该懂。他去剑桥面试建筑系主任的时候，人家问他上任后第一个聘谁，他说：“一个木匠。“面试官追问：“哪位大建筑师？“他不松口。那木匠之后呢？“一个石匠。"——结果可想而知，他没拿到那个职位。 他的意思说穿了很简单：干活的人应该理解自己在用什么方法干活。这种知识不该被少数专家垄断，应该属于每一个建造者和使用者。 当我把自己的写作模式提取出来时，就是这个道理。以前那些"感觉"一直锁在直觉里，现在变成了我能拿出来看、拿出来改的东西。所以这些指令不只是写给 Claude 的。它们是写给我自己的——就像一面镜子，让你看清自己这些年积累了什么本事。 有个叫 Michael Polanyi 的哲学家说过一句话特别贴切：“我们知道的，比我们说得出来的多得多。“他的意思是，人类大部分精妙的技能都是"隐性"的——融化在身体的习惯里、直觉里，很难用语言完全描述。给 AI 写指令这件事厉害的地方就在这里：它强迫你把这些说不出来的东西说出来。如果你不把自己的经验和判断变成清晰的文字，AI 产出的东西就会"看着挺好，但总觉得少了点什么”——及格但空洞。你不得不把你知道的东西告诉它。