用途
Vision Forge 用于创建或修订一份范围明确的愿景文档，供外部相关方阅读：说明工作服务于谁、为何存在、哪些成果重要，以及哪些边界指导决策。它明确区分愿景与 PRD、路线图、战略备忘或任务清单——愿景是长期意图层，让用户、贡献者、维护者、合作伙伴和运营者理解这份工作是为了什么，以及什么不适合纳入。
默认假设
VISION.md 默认不是智能体指令文件。智能体只有在项目指令要求时才可参考它来了解产品意图。运营性的智能体规则应放在 AGENTS.md、技能或单独的 loop/agent 策略中。
范围优先
愿景可以有不同的范围，起草前应先明确愿景管辖的边界，不要把多层范围混成一份含糊文档。常见范围包括：
- 组织 / 操作系统——使命、价值观、治理、角色、预算和长期运营约束。
- 产品 / 业务线——产品服务于谁、长期成果、定位、非目标和投入边界。
- 项目 / 仓库——项目意图、目标用户、架构方向、贡献政策、合并/签核门槛和维护优先级。
- 功能 / 子系统——目标用户成果、局部非目标、约束以及该子系统有效的证据。
- Loop / agent 程序——允许的自主性、升级门槛、预算、评审/裁判政策以及学习/修订规则；这通常是配套政策，而不是面向外部的 VISION.md 本身。
按惯例使用 VISION.md 表达仓库/项目级外部意图。对于更小或更大的范围，可选择更清晰的路径，例如 docs/vision.md、docs/<feature>/vision.md、.brain/areas/<area>.svx 或 PRD 中的一节。产物名称不如范围和受众明确重要。父愿景约束子愿景：功能愿景可以细化产品意图，但不应悄悄推翻产品或组织愿景。
受众优先
在选择章节前先明确文档面向谁：
- 外部相关方：用户、贡献者、合作伙伴、买家、社区成员、审计人员、核心循环之外的维护者；这是 VISION.md 的常规受众。
- 内部运营者：负责人、维护者、员工、支持人员、发布经理；他们可能需要私有说明或运营章程。
- 智能体 / 循环：规划者、执行者、评审者、裁判、loop master；他们需要在别处获得明确的操作指令。
如果希望智能体执行该愿景，应添加配套指引，而不是把内部循环规则塞进外部愿景。示例：
AGENTS.md excerpt
Read VISION.md for product intent, target users, non-goals, and decision boundaries before planning substantial work. VISION.md is not permission to bypass this file. Operational rules, commands, validation, and sign-off gates live here.
先阅读
提问前先检查已有材料：
- 已有的 VISION.md、AGENTS.md、README.md、CONTRIBUTING.md、文档、ADR、issue 模板和 changelog
- 项目笔记、PRD、路线图或规划文档（如存在）
- 当愿景需要反映实际架构时，查看近期代码形态
- 仅在能揭示当前优先级或治理痛点时查看开放的 issue/PR
如果证据已能回答某问题，就不要重复提问。先基于已有凭证起草，再只询问缺失的决策。
一次只问一个问题
使用以下格式：
Question: ...
My recommendation: ...
Why: ...
提问应能迫使选择分支，而不是写小作文。好的问题会识别一个决策：
- 这个项目要帮助的第一个真实用户/运营者是谁？
- 即使实现变化，也应当存活的长期成果是什么？
- 贡献者或维护者默认应把哪些工作视为安全？
- 哪些工作必须停止并等待负责人/维护者签核？
- 哪些诱人的相邻工作明确不属于本项目？
- 什么证据能告诉一个循环它让项目变得更好了？
草稿形态
一份强有力的项目/仓库 VISION.md 通常每个章节一屏可容纳：
Vision
<一两段：这个项目是什么，为什么存在。>
Who We Serve
- 主要用户：
- 次要用户：
- 不适合：
Outcomes
- 长期成果 1
- 长期成果 2
- 长期成果 3
Current Priorities
- 优先级一
- 优先级二
- 优先级三
Actors
- 主要用户 / 受益者：
- 贡献者 / 构建者：
- 维护者 / 负责人：
- 合作伙伴 / 外部系统：
- 非受众：
Merge by Default
- 原因明确且风险可控的安全缺陷修复
- 不改变政策的文档修复
- 编码既有预期行为的测试/检查
- 遵循现有架构且不增加维护负担的小改进
Needs Sign-Off
- 新产品界面或用户承诺
- 架构、依赖、工具链、认证、隐私、安全、部署、定价或数据保留变更
- 改变公共 API、用户数据、计费或运营风险的行为
- 大型重构或会显著增加维护复杂度的变更
Will Not Do For Now
- 诱人的非目标 1
- 诱人的非目标 2
Decision Boundaries
- 默认安全：
- 需要负责人签核：
- 有意义变更所需的证据：
- 预算 / 维护约束：
Amendment Policy
当证据表明项目方向或治理有误时，本文档可以变更。智能体可以附上凭证提议修订。由人类负责人批准变更。
按范围和受众调整标题。如果某章节只会增加冗余，就不要强行加入。对于仓库/项目范围，应保留合并/签核或决策边界章节，因为外部贡献者需要知道哪些变更合适。如果需要智能体/循环治理，应创建或更新 AGENTS.md、技能或单独的 loop 政策作为配套产物。
规则
- 在靠近顶部处说明范围和受众边界。
- 短到智能体真的会读。
- 使用平实语言，避免高管式空话。
- 优先明确权衡，而不是价值口号。
- 将愿景与任务分开：任务放在 PRD、计划、issue 或待办文档中。
- 将外部愿景与内部流程分开：命令、本地工作流细节和智能体自主性规则放在 AGENTS.md、技能或配套 loop 政策中。
- 包含非目标；它们通常是最有用的部分。
- 如果项目已有强有力的愿景，做外科手术式修订，而不是重写。
- 如果拟议愿景与当前代码/文档矛盾，应指出矛盾并询问哪个真相应优先。
输出
完成后报告：
- 创建/更新的 VISION.md 路径
- 捕获的关键决策
- 新增的签核 / 决策边界
- 尚未解决的开放问题
- 如需要，创建或更新的配套智能体/循环政策
- 如有，运行的验证