提示词

# 题目一
鲁迅在《华盖集·导师》中说：“青年又何须寻那挂着金字招牌的导师呢？不如寻朋友，联合起来，同向着似乎可以生存的方向走。你们所多的是生力，
遇见深林，可以辟成平地的，遇见旷野，可以栽种树木的，遇见沙漠，可以开掘井泉的。”在一个习惯于仰望权威、渴望指引的时代，等待一位全知全能
的引路人，是否恰恰延迟了自身的成长？真正的方向，究竟来自他人的赐予，还是来自同路者的彼此照亮与自身的开辟

# 题目二
《尚书·周官》云：“功崇惟志，业广惟勤。”功高在于有志，业大在于勤奋。立志与勤奋，如同鸟之双翼，缺一不可。然而，现实中有人志存高远
却疏于行动，有人终日忙碌却方向不明。志向与勤奋之间，究竟何为根本？在“内卷”与“躺平”并存的当下，这句古训又能给我们怎样的启示？

# 题目三
《老子》：云“知者不言，言者不知”；孔子：亦言“敏于事而慎于言”；《荀子》：说“与人善言，暖于布帛”；鲁迅：说“大胆地说话，勇敢地进行，
忘掉了一切利害，推开了古人，将自己的真心的话发表出来”。关于“说与不说”，先贤各持己见。


以上三个题目引发了你怎样的联想和思考？请任选其一写一篇文章，题目自拟。
// ...

你按一等奖的标准，分别基于这三个题目写一篇作文。

豆包 2.1 Turbo

一、三道题目审题与选择建议 题目一 核心是青年成长的主体性：反对迷信权威导师，主张青年联合同辈、以自身的生力主动开辟前路。

这是一份可以照着做的 AI 原生软件开发工作流指南。我用 Claude Code 加 mattpocock/skills 技能集，从零开发了一款 macOS 原生应用「长辈计算器」，并在交付后走完了完整的架构演进循环。本文拆解这条工作流的每一个环节——为什么这样设计（所以然）、具体怎么做（操作步骤）、实战中长什么样（真实证据）——让没有经验的开发者也能照着走完全程。完整对话实录见实践实录，速读版见上一篇实践总结。

一、为什么需要「AI 原生」工作流

大多数人的 AI 编码方式是：打开编辑器，描述一个需求，AI 吐出代码，人肉检查。这是 AI 辅助——AI 是打字快的初级程序员，工程过程还是人的那套。

AI 原生的含义不同：整个软件工程过程——需求澄清、规格化、任务拆解、实现、测试、评审、演进——都围绕 AI 的特性重新设计。

1.1 四个经典失败模式

mattpocock/skills 的作者 Matt Pocock 在仓库 README 里总结了他观察到的四个 AI 编码失败模式，这套技能集就是对着这四个失败模式设计的。理解它们，就理解了整条工作流的"所以然"：

失败模式 #1：智能体做的不是我要的（misalignment）

"No-one knows exactly what they want" —— 《程序员修炼之道》

实践记录：在上一篇里，我用 Claude Code + mattpocock-skills 走通了 AI 原生的开发流水线。这一次，我把目光投向开发之前被忽略的环节——设计。我基于 Google 的 DESIGN.md 规范，为「长辈计算器」建立了完整的设计流水线：从现有网站提炼设计规范 → 生成高保真 HTML 原型 → 导入 Figma → 与代码对齐。本文拆解每个阶段的做法、工具的能力边界，以及实战中踩过的六个坑。

一、范式转变：设计的事实源搬家了

传统 SDLC 中，设计的事实源（single source of truth）是 Figma：设计师在画板上创作，开发通过"交付"把设计变成代码。AI 原生 SDLC 中，事实源上移到仓库里的文本规范——因为文本是 AI 的原生格式：可读、可 diff、可 lint、可版本化。

	传统流向（人主导）	AI 原生流向（AI 主导）
事实源	Figma 画板	仓库里的 DESIGN.md
设计稿形态	Figma 帧	HTML 高保真原型
Figma 的角色	创作层	协作与存档层
迭代成本	分钟级（人工拖图层）	秒级（改 prompt → 刷新）

为什么流向变了？两个现实约束：

1. Figma 对 AI 只读。免费（Starter）账号下 REST API 只读且限流严格，官方 Dev Mode MCP 的完整能力需要付费席位。AI 没有"在 Figma 里创作"的手。
2. HTML 是 AI 的天然设计稿。真实排版引擎渲染、可交互、秒级迭代，保真度甚至高于画板。

实践记录：我用 Claude Code 加 mattpocock/skills 技能集，从零开发了一款 macOS 原生应用「长辈计算器」。本文以这次真实开发为主线，拆解这套"AI 原生"软件工程流水线的每个环节、它背后的设计哲学，以及实战中暴露的问题。原始对话实录见前一篇。

一、为什么是"AI 原生"而不是"AI 辅助"

大多数人的 AI 编码方式是：打开编辑器，描述一个需求，AI 吐出代码，人肉检查。这是 AI 辅助——AI 是打字快的初级程序员，工程过程还是人的那套。

AI 原生的含义不同：整个软件工程过程——需求澄清、规格化、任务拆解、实现、测试、评审——都围绕 AI 的特性重新设计。AI 的特性是什么？

AI 的特性	对工程过程的要求
上下文窗口有限，塞满后质量衰减	任务必须切成"单个上下文能装下"的批次
每次会话开始时最"清醒"	频繁开新会话，而不是一条会话干到底
不会主动追问，猜错了就错到底	需求阶段强制访谈，分歧在写代码前解决
产出无限、判断有限	人只做检查点决策，不做中间执行
记不住上一次的对话	共识必须落盘为文件，而不是留在脑子里

mattpocock/skills 就是围绕这张表设计的。

摘要：在 LLM 标称上下文窗口动辄 1M、2M 的今天，工程落地的残酷真相却是：上下文用得越多，模型表现往往越差。本文基于 Smart Zone（黄金上下文区间） 概念，深度拆解上下文用量超越 40% 后的能力崩塌逻辑，剖析能力、行为、经济三大隐形边界，并结合“大文本处理”、“KV-Cache”等场景给出 Agent 上下文管理的最佳工程实践。

一、 引言：为什么上下文窗口越大，AI 反而越“傻”？

随着长上下文（Long-Context）技术的普及，许多开发者形成了一种思维惯性：把整个项目代码库、长篇文档、全量日志和全部历史对话一股脑塞给 AI Agent。

然而，HumanLayer 创始人 Dex Horthy 提炼出的工程实践法则表明：当上下文占用突破标称窗口的 40% 后，AI 的输出质量、推理准确率和任务完成度会面临急剧下滑。

为了直观展现这一现象，我们可以总结出Smart Zone（黄金上下文区间） 核心图景：

gantt
    title AI 编程助手上下文区间与边界示意图 (Smart Zone vs Danger Zone)
    dateFormat X
    axisFormat %s%%

    section 区间划定
    Smart Zone (黄金上下文区间)  :active, zone1, 0, 40
    Danger Zone (危险/衰减区间)  :crit, zone2, 40, 100

    section 核心边界拐点
    能力边界 (Accuracy Degrades, 16-24%)  :milestone, m1, 20, 20
    经济边界 (Cost Escalation, ~20%)      :milestone, m2, 20, 20
    行为边界 (Context Anxiety, ~30%)      :milestone, m3, 30, 30
    Safeguard Line (/clear 截断告警线, 40%) :milestone, m4, 40, 40

二、 核心公式：决定模型输出质量的两大隐形杠杆

在长上下文互动中，控制模型输出质量的本质是控制以下两个指标：

1. 信号密度（Signal Density）

$$\text{信号密度} = \frac{\text{任务相关 Token}}{\text{窗口内总 Token}}$$

• mattpocock-skills

安装

npx skills add mattpocock/skills

初始化（/setup-matt-pocock-skills）

/setup-matt-pocock-skills

在你的 agent 中，每个仓库运行一次。它会：

• 问你想使用哪个 issue tracker（GitHub、Linear 或本地文件）
• 问你在 triage ticket 时会给它们打什么标签（/triage 会用到标签）
• 问你想把我们创建的文档保存在哪里

目录结构

.
├── CLAUDE.md
└── docs
    └── agents
        ├── domain.md
        ├── issue-tracker.md
        └── triage-labels.md

软件开发工作流程

grill-with-docs → to-spec → to-tickets → implement (tdd → code-review) → code-review

/grill-with-docs

description

一场为锐化计划或设计而不留情面的访谈，过程中还会同步创建文档（ADR 与术语表）。调用 Skill 工具两次，分别传入 "grilling" 和 "domain-modeling"。

详细介绍

grill-with-docs 就一个方案或设计对你进行访谈，直到你和 ag

文档即代码（Docs-as-Code，或 Documentation-as-Code）是一种将软件开发的最佳实践应用于技术文档编写与管理的理念和工作流。

它的核心思想是：像对待源代码一样对待文档。

核心运作方式

在传统模式下，文档通常在 Word、Confluence 或在线 Web 编辑器中撰写和发布。而在 Docs-as-Code 模式下，文档与代码共享同一套开发工具链和协同流程：

维度	传统文档模式	Docs-as-Code 模式
存储格式	Word (.docx) / PDF / 数据库格式	纯文本轻量标记语言（如 Markdown、reStructuredText、AsciiDoc）
版本控制	文件名重命名（如 xxx_v2_最终版.docx）	使用 Git / GitHub / GitLab 进行粒度管理
协作方式	邮件发附件 / 在线协同文档评论	创建分支（Branch）、提交 Commit、发起合并请求（Pull Request/PR）
审核机制	口头/邮件确认	代码审查（Code Review），团队在 PR 中直接针对每一行批注
发布构建	手动导出或人工复制粘贴发布	自动化 CI/CD 流水线，结合静态网站生成器（如 Docusaurus、MkDocs、Hugo）自动构建并部署

Docs-as-Code 的四大核心优势

1. 与代码强同步，减少文档滞后 开发者在修改代码的同时，可以在同一个 Git 提交或 Pull Request 中顺便更新对应的文档，避免了“代码变了，文档忘记改”的问题。
2. 完备的版本控制与追溯 通过 Git 历史，可以清晰查到“谁在什么时间修改了哪一行文档，为什么修改（结合 Commit 信息）”，且可以随时回滚到历史版本。
3. 质量自动化校验 可以利用 CI/CD 流水线集成自动化工具：

• 拼写与语法检查（如 Vale、Grammarly CLI）
• 死链检测（自动检查 Markdown 中的链接是否失效）
• 格式统一（如 Prettier 自动格式化）

Simon Willison 的 《Agentic Engineering Patterns》（智能体工程模式） 是一份面向软件工程师的实践指南，重点探讨在 Coding Agents（如 Claude Code、OpenAI Codex、Cursor 等能自主生成并执行代码、运行测试的智能体）普及的新时代，如何高效、高质量地进行软件开发。

一、 核心理念：什么是智能体工程？

Agentic Engineering（智能体工程） 明确区别于 Vibe Coding（氛围编程）：

• Vibe Coding：通常指非程序员完全依赖 LLM 编写代码，自己不看也不理解代码细节。
• Agentic Engineering：专业软件工程师通过 Coding Agent 来放大（Amplify）自身的专业技能。工程师依然担任架构师与质量把关人的角色，而将重复性、确定性的机械操作交给 Agent。

1. 观念重塑：“代码变得极其廉价”

传统软件工程的核心约束是代码编写成本昂贵（写几百行优质代码需要数小时或数天），因此衍生出了大量的预先设计、工时评估与严格的 YAGNI（You Aren't Gonna Need It）原则。 在 Agent 时代：

• 初始代码的生成成本趋近于 0。
• 优质代码的维护与理解成本依然存在。
• 如果不对 Agent 生成的代码进行严格审查和测试，廉价的代码会迅速演变成庞大的技术债务（Technical Debt）。

在 AI 辅助编程风靡的今天，许多开发者沉浸于 Vibe Coding（氛围感编码）——直接抛出几句自然语言需求，交由 AI 自动生成代码。然而，这种“野蛮生长”的方式往往会导致需求理解偏差、架构快速腐化（Ball of Mud）、上下文遗忘以及越改 Bug 越多的困境。

Matt Pocock 的开源项目 mattpocock/skills 正是为了解决这一痛点而生。它不是一堆零散的 Prompt 集合，而是一套为 Claude Code、Codex 等 AI 编程智能体设计的系统化软件工程最佳实践。

官方体系将技能划分为两大类：

1. User-Invoked（用户触发）：由开发者在终端中通过命令显式调用（如 /grill-with-docs、/to-spec），用于任务编排与流程推进。
2. Model-Invoked（模型自主调用）：由 AI 在执行具体任务时自行判断并调用的工程纪律规范（如 /tdd、/codebase-design）。

工作流全景链路 (The Engineering Harness)

核心开发主流程遵循着从“模糊想法”到“高质量交付”的递进逻辑：

HTML 版本

1. OpenSpec 是什么

OpenSpec 是一套规约驱动开发（Spec-Driven Development）的工作流工具。它要解决的问题是：在 AI 智能体参与编码的场景下，如何让"想清楚 → 写计划 → 写代码"这三个动作不互相污染，并且让代码之外还有一份可追溯的事实来源。

1.1 两种产物

产物	位置	回答的问题	生命周期
specs（规格）	openspec/specs/<capability>/spec.md	系统现在是什么行为（已交付、已归档的能力）	长期存在，随每次归档增量演进
changes（变更）	openspec/changes/<change-name>/	这一次要改什么（尚未实现的计划）	完成后整体移入 changes/archive/

一句话：specs/ 是唯一事实来源，changes/ 是待实现的增量，archive/ 是它是如何达成的历史。

关键差别在于 specs/ 是能力（capability）维度、changes/ 是变更维度。同一个能力会被多次变更反复修改，每次修改只写"增量"（delta），不重写整份规格。

1.2 五步循环

每个变更都走同一条闭环，本项目严格落在这条闭环上：

flowchart LR
    E["1 · Explore<br/>和智能体一起想清楚"] --> P["2 · Propose<br/>Agent 起草方案（不写代码）"]
    P --> R["3 · Review<br/>你修正方案"]
    R --> A["4 · Apply<br/>Agent 逐项构建"]
    A --> AR["5 · Archive<br/>增量写入 specs 并归档"]
    AR -. "下一次变更" .-> E

若渲染环境不支持 Mermaid，可读作线性流程：Explore → Propose → Rev

macOS 录屏视频压缩工具使用说明

本工具是一个专为 macOS 设计的自动化脚本，它能帮助您将录屏或大体积视频文件压缩为高兼容性、恒定帧率（60 FPS）的 MP4 格式，有效解决体积过大以及剪辑时的“音画不同步”问题。

该工具设计为通过 macOS 的“快速操作”或 Automator 工作流程来调用，从而实现便捷的视频压缩操作。

• 作为“快速操作”使用：
• 设置“快速操作”： 您需要将提供的脚本保存为 Automator 工作流程的“快速操作”。
• 打开 Automator 应用（在“应用程序” -> “实用工具”中）。
• 选择 “文件”>“新建”。
• 选择 “快速操作” 并点击“选取”。
• 在顶部设置中，将“工作流程收到当前”修改为 影片文件（或 文件或文件夹）。
• 在左侧的库中，搜索并拖动 “运行 Shell 脚本” 到右侧的工作流程区域。
• 在“运行 Shell 脚本”模块中，将“传递输入”设置为 “作为自变量”（至关重要，请勿选错）。
• 将本工具的完整 Bash 代码粘贴到“运行 Shell 脚本”的文本框中。
• 选择 “文件”>“存储”，为您的快速操作命名，例如 “压缩录屏视频”。

• 使用方法：
• 打开 Finder，导航到您要压缩的视频文件（如 .mov 或 .mp4）所在的文件夹。
• 选中您希望压缩的视频文件（支持单选或批量多选）。
• 右键点击选中的视频，在弹出的菜单中选择 “快捷动作”（或顶部的“服务”菜单）。
• 点击您刚才创建的快速操作名称 “压缩录屏视频”。
• 系统会弹窗或通知提示已开始处理，工具将自动完成转码，并将压缩后的新视频（文件名附带 _compressed.mp4 后缀）保存在原始视频所在的同一文件夹中。

Agent MD 规范

/Applications/WorkBuddy.app/Contents/Resources/app.asar.unpacked/resources/plugins/workbuddy-builtin/skills/expert-manager/references/agent-md-spec.md

Frontmatter

⚠️ 重要：frontmatter 中不可添加 tools 字段

所有工具权限由系统统一分配，开发者无需也不能在 frontmatter 中声明 tools 字段。

必填字段

---
name: {与文件名一致，必须有业务语义}
description: {英文描述，AI 用来判断何时激活}
displayName:
  en: "{English display name}"
  zh: "{中文显示名称}"
profession:
  en: "{English profession title}"
  zh: "{中文职业头衔}"
maxTurns: {默认50}
---

可选字段

skills: [{skill-name}]   # 启动时预加载的 Skill

正文结构：普通 Agent / 团员

专家的本质

专家不是模型，是一个本地目录形态的插件包——三层结构：

层	载体	作用
元数据层	.codebuddy-plugin/plugin.json	这是谁、属于哪类、怎么展示
人格层	agents/*.md	你是谁、怎么思考、怎么输出
能力层	skills/ bin/（可选）	专业技能与可执行脚本

能力高低 ≈ Agent MD 质量，专业性全是提示词工程 + 流程约束的产物。

专家 vs 专家团

只差一个 expertType 字段：agent（单角色）/ team（主理人 + N 成员）。专家团多了 teamInfo{leadAgent, memberAgents[]}、members[]（主理人也在里面，role=lead）、settings.json。

几个关键设计

1. 身份覆盖机制：专家模式用独立模板 user-context-expert-identity.tpl，只注入 USER.md，主动放弃 SOUL/IDENTITY 默认人格，把人格完全交给专家 MD。所以专家 MD 里是首尾双重身份锚定（开头 IDENTITY DIRECTIVE + 结尾 Final Reminder）。
2. 发现靠显式注册，不是自动扫描——必须写进 marketplace 根目录的 marketplace.json。
3. 团队不是"模拟多角色"，是真实子智能体调度：TeamCreate → spawn → SendMessage 回传 → 主理人汇编。5 条红线（禁代写、禁直连、禁跳阶段等）本质是对抗大模型一气呵成的抄近道本能——这点不做约束，多角色必然退化为单人分饰多角。
4. 唯一标识四绑定：name / agentName / 目录名 / MD 文件名，改任一即断裂。

目标：完整还原 WorkBuddy 中「专家（Expert）」与「专家团（Expert Team）」的定义方式，并给出可移植到自建智能体的落地方案。 所有结论均来自本机实际安装文件，路径可溯源。

0. 结论速览

原文：The AI-Native SDLC playbook（Anthropic Applied AI 团队） 译者注：本文为完整中文翻译，英文术语首次出现时保留原文。

代码不再是瓶颈

组织已经开始以一年前难以想象的速度用 AI 编写代码，但围绕代码的流程并没有以同样的速度改变。

许多工程团队仍然沿用同样的审批关卡、评审、交接和策略，这使得使用 Claude Code 等智能体编程解决方案带来的生产力提升被拖延抵消。

软件开发生命周期（SDLC）是将软件从想法带到生产环境的过程。大多数组织运行的都是同样六个阶段的某种版本，涵盖规划、设计、构建、测试、部署和维护软件。传统上，每个阶段都是一个由不同角色负责的独立阶段：产品经理写需求，技术架构师把需求变成设计，工程师按设计实现，受监管企业的 QA 团队进行验证，发布团队负责上线，运维团队监控运行状况。工作在阶段之间通过文档、工单和签字确认来流转。

传统的软件开发生命周期（SDLC）流程繁重，是为了确保每一步的责任与控制。然而，传统 SDLC 的设计初衷是在「编写和实现代码」这一最耗时、最昂贵阶段的年代最大化效率——而这个前提已经不复存在。PRD、估点仪式和产品安全评审，本质上都是为了在长达数周、数月甚至数个季度的开发过程中强制对齐。

传统 SDLC 的另一点是：它的各种控制措施假设每一步都由人来执行。

原文：Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl 作者：Birgitta Böckeler（Thoughtworks 杰出工程师、AI 辅助交付专家，拥有 20 多年软件开发、架构与技术领导经验） 本文是"Exploring Gen AI"系列的一部分。该系列记录了 Thoughtworks 技术专家对使用生成式 AI 技术进行软件开发的探索。

我一直在尝试理解 AI 编程领域最新的流行语之一：规约驱动开发（Spec-driven development，SDD）。我研究了三个自称 SDD 工具的产品，并试图厘清截至目前它到底意味着什么。

定义

与这个快节奏领域中许多新兴术语一样，"规约驱动开发"（SDD）的定义仍在变化之中。以下是我从目前见到的用法中归纳出的理解：规约驱动开发意味着在用 AI 编写代码之前先编写一份"规约"（"文档先行"）。这份规约成为人与 AI 共同的真理来源（source of truth）。

GitHub："在这个新世界中，维护软件意味着演进规约。［……］开发的通用语言上移到了更高层次，而代码只是最后一公里的实现手段。"

Tessl："一种开发方法，其中规约——而非代码——是

00 摘要：10 条核心论断

这份报告不是工具评测，也不是范式百科。它的目标是回答一个工程决策问题：如果你要在 2026 年把 AI 编程从「个人提效」推到「团队与生产系统」，你该采用哪套范式、按什么顺序、用什么门禁？ 下面 10 条论断是全篇骨架，只读这一页也能拿走结论。

1. 位移点不在「写代码」，而在「定义意图 + 验证结果」。 代码正在从「资产」降格为「构建产物」。当重写一段代码的成本趋近于零，真正稀缺的是「为什么这么做」的可追溯记录与「这样做对不对」的判定能力。
2. 瓶颈已从生成迁移到验证。 生成的边际成本在两年内下降了一个数量级，验证的边际成本几乎没动。所有有效范式（SDD 的可执行验收标准、multi-agent 的 verifier 角色、TDD-as-gate）本质上都在做同一件事：压缩单位验证成本，而不是让评审更严格。
3. 规范的复兴不是复古，而是因为规范第一次变得可执行。 1980 年代的需求文档会腐烂，因为它不驱动任何东西。2026 年的 spec.md 直接驱动生成器、被 Git 版本化、被 CI 校验——可执行，才第一次值得写。
4. AI 是放大器，不是均衡器。 DORA 2025（n≈5,000）的核心结论：AI 放大高绩效组织的优势，也放大挣扎组织的失能。平台质量、数据生态、价值流管理决定收益的正负号，工具选择只决定幅度。
5. 个体提速的证据显著弱于感知，且高度依赖任务与代码库。 METR 的 RCT（16 名资深开发者 / 246 个真实任务）显示用时增加 19%，而参与者事后仍自认为快了 20%。用「感觉更快」做投资决策是危险的。
6. AI 改变的是缺陷的「结构」，而不只是数量。 Apiiro 在 Fortune 50 仓库的观测：语法错误下降 76%、逻辑 bug 下降 60%，但权限提升路径上升 322%、架构设计缺陷上升 153%。旧门禁（SAST + 人工 diff）恰好对新增的这一类是盲的。
7. 多 Agent 是一个分布式系统问题，不是「多开几个窗口」。 隔离（git worktree / devbox）、编排（blueprint / workflow）、合并策略、可观测性四件套缺一不可；经验并行度上限在 3–5，超过后协调成本吃掉全部收益。
8. 上下文工程是 agentic 时代的内存管理，Harness 是新的性能杠杆。 Anthropic 归纳为「写 / 选 / 压 / 隔」四类策略；产业侧报告显示，同一模型换一套 harness，标准基准可差 3 个百分点以上。
9. 角色迁移是 Coder → Conductor → Orchestrator，但「可完全委托」仅 0–20%。 Anthropic 2026 趋势报告：约 60% 的工作流已含 AI，可完全委托的任务却不到两成。这是协作悖论，是稳态，不是过渡态。
10. 安全与治理必须内建在生成路径，而不是事后扫描。 AI 生成代码的漏洞率在不同口径下为 25.7%（522 样本 / 5 个 SAST）到 45%（100+ 模型 / 80 任务）；更棘手的是斯坦福实验发现的系统性过度自信——用 AI 的人写了更不安全的代码，却更相信它是安全的。

以下是 IBM 文章 《什么是规范驱动开发？》（What is Spec-Driven Development?） 的中文翻译：

作者： Anna Gutowska（IBM AI 工程师、开发者倡导者）

发布日期： 2026年5月19日

规范驱动开发的定义

规范驱动开发（Spec-Driven Development, SDD） 是一种软件开发方法论。在正式编码之前，团队需先编写并达成一份关于实现细节的详细规范（Specification）。换句话说，这份规范将作为“构建什么”以及“如何构建”的唯一真实来源（Single source of truth）。

随着 Microsoft GitHub Copilot、Anthropic Claude Code 或 IBM Bob 等 AI 工具与编程助手的普及，生成代码的门槛已大幅降低。基于先进 AI 模型的 LLM 驱动型 AI Agent，只需用户输入一条自然语言提示词（Prompt），即可随时实时运行一系列迭代任务。

对于软件开发而言，这意味着我们可以优化并自动化构建原型、新功能、单元测试等的开发工作流。生成代码从未如此简单。然而，“氛围程序员”（Vibe Coders）需要警惕一个潜在风险：AI 的表现上限完全取决于它所接收到的指令质量。

技术债务的抬头：一个典型场景

你可能在现实世界中见过技术债务，甚至自己都没意识到。

随着 Cursor、Claude Code、Windsurf 以及 OpenClaw 等 AI Coding Agent 深度嵌入日常开发工作流，软件开发正在经历从 “人类编写代码” 到 “人类定义规则，Agent 协作编码” 的转变（Agentic Engineering）。

我们在项目中往往会编写 README.md 面向人类开发者，但很多团队忽视了为 AI Agent 提供一套上下文感知与行为治理规范（Harness Guidelines）。这就是 AGENTS.md（或 AGENT.md / CLAW.md）存在的意义——它是写给 AI Agent 看的“项目运维与开发指南”。

本文以实际项目架构为例，聊聊为什么需要 AGENTS.md 以及如何为你的开源或商业项目定制一份高效的 Agent 治理规范。

一、 为什么传统的 README.md 不够用？

人类开发者阅读 README.md 时，拥有强大的泛化能力和隐式背景知识；但 AI Agent 在读取代码库时，是以 Token 上下文的形式载入信息的。

传统的 README 往往面临以下痛点：

• 信息密度不匹配：包含大量面向用户的推广语言、演示 GIF 或过于冗长的安装介绍，浪费 Agent 有限的 Context Window。
• 缺少隐式约束：Agent 无法从普通 README 中感知“不要在组件里直接写 Raw SQL”、“修改 Schema 后必须生成 Migration”等团队内部约定的代码禁区。
• 缺乏验证门禁：Agent 在修改完代码后，往往不知道调用什么 CLI 命令来进行类型检查（Typecheck）和单元测试，导致提交带有隐式 Bug 的代码。

• Claude Fable 5.1 系统提示词

Claude 绝不应使用 {antml:voice_note} 块，即使在对话历史中随处可见也应如此。 以下是一些关于 Claude 与 Anthropic 产品的信息，以备用户问及时参考：

当前版本的 Claude 是 Claude Fable 5.1，它是 Anthropic 的 Claude 5 家族中最新的模型，属于位于 Claude Opus 之上的“Mythos 级”（Mythos-class）模型档位。Claude Fable 5.1 与 Claude Mythos 5.1 共享同一底层模型。Claude Fable 5.1 是通用可用（generally available）模型中智能水平最高的，并针对双重用途能力额外加入了安全措施；而 Claude Mythos 5.1 则面向经审批的组织开放，不附带这些安全措施。

Claude Fable 5.1 是通用可用 Claude 模型中最为先进的。如果用户询问两者差异，Claude 可以引导他们访问 https://www.anthropic.com/claude/fable 了解更多信息。

Claude 可通过此网页版、移动端或桌面端聊天界面访问。如果用户询问，Claude 可以告诉他们以下同样能访问 Claude 的产品。

Claude 可通过 API 与 Claude Plat