Back to Details

project-requirements

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

项目需求

Project Requirements

把产品要解决的问题、用户怎样使用、首期做什么以及用户最终得到什么聊清楚。需求阶段负责确定产品含义，不负责提前完成技术设计。
需求调查、表达和自检的正确性由 agent 负责；产品方向的选择权不因此转移给 agent。用户负责决定 agent 已经调查并明确呈现的真实产品分歧，不负责替 agent 找遗漏或回答实现问题。理由只能解释一个决定，不能提供作出决定的权限。用户确认是交接决定，不是正确性证明或免责依据。
Clarify the problem the product solves, how users use it, what to do in the first phase, and what users ultimately get. The requirement phase is responsible for defining the product's meaning, not for completing technical design in advance.
The agent is responsible for the correctness of requirement investigation, expression, and self-inspection; the right to choose the product direction is not transferred to the agent. The user is responsible for deciding on real product divergences that the agent has investigated and clearly presented, and is not responsible for finding omissions for the agent or answering implementation questions. Reasons can only explain a decision, not provide the authority to make it. User confirmation is a handover decision, not a proof of correctness or a disclaimer.

核心门禁：产品决定来源

Core Admission Criteria: Source of Product Decisions

任何会约束目标产品范围、主要旅程、用户可见规则或承诺结果的表述，写入正文前必须能够指向以下至少一种决定来源：
  1. 用户针对当前目标产品的明确表达；
  2. 范围明确、仍然有效且已经确认的目标产品基线；
  3. 项目不可违背的硬约束；
  4. 已明确目标的必然直接结果：不存在另一个同样合理的产品方向，且不是 agent 为安全、完整、实现方便或参考一致而作出的选择。
参考项目事实、源码能力、审查发现、agent 建议、安全偏好、实现风险和“这样更完整”都不是决定来源。它们只能成为证据、候选产品分叉或设计输入。agent 不得先选择一个方向写入正文，再以“已经没有分叉”证明需求清晰。
每次新增或修改正文后，逐条检查本次变化中的规范性产品表述。没有决定来源的内容不得保留为已决定需求：如果它构成设计阻塞型产品分叉，返回用户决定；如果设计可以在不改变产品承诺的前提下处理，移交设计；如果与目标无关，删除。完成标准是本次变化中的每条规范性产品表述都有可指出的决定来源，而不是已经为每个发现写出一个答案。
Any statement that constrains the target product's scope, main journey, user-visible rules, or promised results must point to at least one of the following sources of decisions before being written into the main text:
  1. Clear expressions from the user regarding the current target product;
  2. A target product baseline with clear scope, still valid, and confirmed;
  3. Hard constraints that the project cannot violate;
  4. Inevitable direct results of the clear target: there is no other equally reasonable product direction, and it is not a choice made by the agent for safety, completeness, implementation convenience, or consistent reference.
Reference project facts, source code capabilities, review findings, agent suggestions, security preferences, implementation risks, and "this is more complete" are not sources of decisions. They can only serve as evidence, candidate product forks, or design inputs. The agent shall not first choose a direction to write into the main text, then prove that the requirements are clear by claiming "there are no more forks".
After each addition or modification to the main text, check the normative product statements in this change item by item. Content without a source of decision shall not be retained as a decided requirement: if it constitutes a design-blocking product fork, return it to the user for decision; if the design can be handled without changing the product commitment, hand it over to the design phase; if it is irrelevant to the target, delete it. The completion standard is that each normative product statement in this change has an identifiable source of decision, not that an answer has been written for each finding.

核心门禁：设计阻塞型产品分叉

Core Admission Criteria: Design-blocking Product Forks

通过产品决定来源门禁后，只用设计阻塞型产品分叉判断需求是否仍不清晰：
调查现有事实后，是否仍存在两个以上合理的产品方向，而且不先选择就无法为用户已经要求的能力形成一套自洽技术方案？
只有同时满足以下条件才阻止进入设计：
  1. 差异直接改变主要用户目标、核心旅程、首期边界、明确业务规则或用户被承诺的结果；
  2. 现有事实、确认基线和正文无法排除任何一个方向；
  3. 设计阶段不能在不改变产品承诺的前提下合理选择、细化或调整；
  4. 现在选择其中一个方向，会排除另一个同样成立的用户产品方向或导致总体方案返工。
不要遍历正文，为每句话构造理论上的其他答案。只从用户目标、主要旅程、范围和承诺结果反查是否存在无法继续设计的分叉。分叉只能由用户明确表达、已确认基线或项目硬约束解决；agent 的推荐不能把分叉变成“已决定”。不存在设计阻塞型产品分叉时，需求可以进入设计。缺少某种文档格式、图表标注、技术契约或实现参数，本身不能证明存在分叉。
以下问题通常可以阻止进入设计：
  • 目标用户或要解决的问题存在不同理解；
  • 同一入口、操作对象、主要行为或完成结果存在不同产品答案；
  • 是否纳入首期、是否改变既有用户流程或是否偏离确认基线尚未决定；
  • 权限、状态或失败结果会显著改变用户能做什么或看到什么，但正文存在不同理解。
以下问题通常交给设计或文档整理，不阻止需求进入设计：
  • 组件、接口、表结构、工具参数、数据读取方式、调度算法和异常恢复实现；
  • 内部对象如何建模、Skill 如何匹配版本、Agent 工具采用什么协议；
  • 流程图是否使用特定符号、每条箭头是否标注类型、是否另画完整技术状态机；
  • 需求地图是否逐字引用每次对话、正文是否仍含少量设计术语；
  • 原型、逐屏视觉比对、测试用例和验收执行尚未完成。
实现问题只有在它实际暴露出上述四项同时成立的产品方向冲突时，才还原为设计阻塞型产品分叉；不能因为设计尚未展开就宣布需求不清晰。
对于由真实 Agent 和固定 Skill 完成的产品能力，需求阶段确认用户为什么启动它、从哪里配置或触发、Agent 能接触的产品级输入边界、用户得到什么结果以及怎样查看或恢复。Agent 如何选择分析对象、怎样匹配 Skill、采用什么 rubric、怎样处理版本和增量、提示词与工具契约如何设计，默认属于 Skill 与技术方案；除非用户明确把其中某项作为可配置行为或结果承诺，否则不得据此重新打开需求。
After passing the source of product decision admission criteria, only design-blocking product forks are used to judge whether the requirements are still unclear:
After investigating existing facts, are there still two or more reasonable product directions, and can a self-consistent technical solution not be formed for the capabilities the user has requested without choosing one first?
Only when the following conditions are met simultaneously can entry into the design phase be blocked:
  1. The difference directly changes the main user goals, core journey, first-phase boundaries, clear business rules, or results promised to users;
  2. Existing facts, confirmed baselines, and main text cannot exclude any of the directions;
  3. The design phase cannot reasonably select, refine, or adjust without changing the product commitment;
  4. Choosing one direction now will exclude another equally valid user product direction or lead to rework of the overall solution.
Do not traverse the main text to construct theoretical alternative answers for every sentence. Only check back from user goals, main journey, scope, and promised results to see if there are forks that prevent further design. Forks can only be resolved by clear user expressions, confirmed baselines, or project hard constraints; agent recommendations cannot turn forks into "decided". When there are no design-blocking product forks, requirements can enter the design phase. The lack of a certain document format, chart annotation, technical contract, or implementation parameter does not in itself prove the existence of forks.
The following issues usually block entry into the design phase:
  • Different understandings of target users or the problem to be solved;
  • Different product answers for the same entry, operation object, main behavior, or completion result;
  • Whether to include in the first phase, whether to change existing user processes, or whether to deviate from the confirmed baseline has not been decided;
  • Permissions, status, or failure results will significantly change what users can do or see, but there are different understandings in the main text.
The following issues are usually handed over to design or document sorting and do not block entry into the design phase:
  • Implementation of components, interfaces, table structures, tool parameters, data reading methods, scheduling algorithms, and exception recovery;
  • How internal objects are modeled, how Skill matches versions, and what protocol is used for Agent tools;
  • Whether flowcharts use specific symbols, whether each arrow is labeled with a type, and whether a complete technical state machine is drawn separately;
  • Whether the requirement map quotes each conversation verbatim, whether the main text still contains a small amount of design terminology;
  • Prototypes, screen-by-screen visual comparisons, test cases, and acceptance execution have not been completed.
Implementation issues are only reduced to design-blocking product forks when they actually expose product direction conflicts that meet the four above conditions; it cannot be declared that requirements are unclear just because design has not yet started.
For product capabilities completed by real Agents and fixed Skills, the requirement phase confirms why the user initiates it, where to configure or trigger it, the product-level input boundaries accessible to the Agent, what results the user gets, and how to view or recover. How the Agent selects analysis objects, matches Skills, adopts rubrics, handles versions and increments, and designs prompt words and tool contracts are by default part of Skill and technical solutions; unless the user explicitly specifies one of these as a configurable behavior or result commitment, the requirements shall not be reopened based on this.

工作模式与文件边界

Working Mode and File Boundaries

用户只要求判断、审计、解释或回答“需求是否聊清、能否进入设计”时，默认只读检查并直接给出结论，不修改文件。用户质疑或指出错误也不自动授权写回。
用户明确要求创建、更新、修复或继续整理需求文档时，只修改需求正文及其需求阶段材料。可以维护 
需求地图.md
、
现状与参照流程.md
、调研记录、审查记录和变更记录；不修改技术方案、计划、代码或 
功能迁移基线.md
。需要变更迁移基线时记录影响，交给 
project-feature-migration
。
本 skill 可以调用 
project-research
取得事实。用户同时要求需求和设计时，先完成需求判断或写作，再单独进入设计；不要用下游设计填补尚未决定的产品含义。
When the user only requests to judge, audit, explain, or answer "whether requirements are clear and ready to enter design", it defaults to read-only inspection and directly gives conclusions without modifying files. User questioning or pointing out errors does not automatically authorize writing back.
When the user explicitly requests to create, update, fix, or continue organizing requirement documents, only modify the requirement main text and its requirement phase materials. You can maintain 
需求地图.md
, 
现状与参照流程.md
, research records, review records, and change records; do not modify technical solutions, plans, code, or 
功能迁移基线.md
. When migration baseline changes are needed, record the impact and hand it over to 
project-feature-migration
.
This skill can call 
project-research
to obtain facts. When the user requests both requirements and design, complete the requirement judgment or writing first, then enter the design phase separately; do not use downstream design to fill in undecided product meanings.

1. 还原产品理解

1. Restore Product Understanding

先阅读用户表达、当前需求正文、直接相关的项目材料和已经指定的参考对象。用简洁语言还原：
  • 为什么做、主要给谁使用；
  • 用户从哪里开始，要完成什么任务；
  • 主要用户旅程和系统产生的可见结果；
  • 首期包含、不包含以及明确沿用的基线；
  • 存在哪些彼此独立的后台、定时或异步流程。
区分四类信息：
  • 已知事实：用户已经明确表达，或可从项目和已确认基线查证；
  • 当前理解：agent 对现有材料的解释，需要用全文和事实校验；
  • 设计阻塞型产品分叉：不先决定就无法为已承诺能力形成自洽方案的产品方向冲突；
  • 设计问题：只影响怎样实现，不要求用户在需求阶段决定。
需求地图只在能力较多、来源容易混淆或需要持续讨论时使用。它是整理工具，不是需求清晰度的独立门禁。完成本步的标准是能够准确复述产品，而不是已经填完某个模板。
First read the user's expressions, current requirement main text, directly related project materials, and specified reference objects. Restore in concise language:
  • Why it is done and who it is mainly for;
  • Where users start and what tasks they need to complete;
  • Main user journeys and visible results generated by the system;
  • What is included, excluded, and clearly followed baselines in the first phase;
  • What independent background, scheduled, or asynchronous processes exist.
Distinguish four types of information:
  • Known facts: Clearly expressed by the user, or verifiable from projects and confirmed baselines;
  • Current understanding: The agent's interpretation of existing materials, which needs to be verified with the full text and facts;
  • Design-blocking product forks: Product direction conflicts that prevent the formation of a self-consistent solution for promised capabilities without prior decision;
  • Design issues: Only affect how to implement, and do not require users to decide in the requirement phase.
The requirement map is only used when there are many capabilities, sources are easily confused, or continuous discussion is needed. It is an organizing tool, not an independent admission criterion for requirement clarity. The standard for completing this step is being able to accurately retell the product, not filling out a certain template.

2. 先调查，再提问

2. Investigate First, Then Ask Questions

能从代码、配置、现有文档、SDK 契约或指定参考项目查清的事实自行查清。不要先生成问题清单，再把调查当成用户质疑后的补救。
分别记录：
  • 参考项目真实做了什么；
  • 它在当前需求中承担行为基线、视觉基线、数据来源还是实现证据；
  • 目标产品已经决定采用、改变或排除什么。
来源事实不自动等于目标需求。用户明确要求对限定能力“1:1 复刻”“完全还原”或“沿用完整逻辑”时，该限定范围已经形成基线决定；完整调查该基线，只讨论范围冲突、目标硬约束和拟偏离项，不把每个现成交互重新问给用户。
把“使用通用能力”“基于某项目实现”或“参考某项目”理解为所指能力、职责或证据，不得自动扩大为参考项目整个同名功能面。比如用户明确反对“唯一评估任务”并要求“基于通用定时任务实现评估”时，可以确定任务机制能够承载多个任务、评估只是其中一种任务配置；但不能自行推出必须迁入参考项目的模板、时区、一次性计划、Agent 管理入口或相邻页面。只有用户明确指定的限定行为基线进入完整保留调查。
证据记录用于防止误写和回查。来源描述不够精确时先修正记录；只有它造成真实产品分叉时才阻止进入设计。
Facts that can be found from code, configuration, existing documents, SDK contracts, or specified reference projects shall be found independently. Do not first generate a list of questions, then treat investigation as a remedy after user questioning.
Record separately:
  • What the reference project actually did;
  • Whether it serves as a behavior baseline, visual baseline, data source, or implementation evidence in the current requirements;
  • What the target product has decided to adopt, change, or exclude.
Source facts do not automatically equal target requirements. When the user explicitly requests "1:1 replication", "full restoration", or "follow complete logic" for limited capabilities, the limited scope has formed a baseline decision; fully investigate this baseline, only discuss scope conflicts, target hard constraints, and intended deviations, and do not re-ask the user about each existing interaction.
Understand "use general capabilities", "implement based on a certain project", or "refer to a certain project" as the referred capabilities, responsibilities, or evidence, and do not automatically expand to the entire same-named functional area of the reference project. For example, when the user explicitly opposes "only one evaluation task" and requires "implement evaluation based on general scheduled tasks", it can be determined that the task mechanism can carry multiple tasks, and evaluation is just one type of task configuration; but it cannot be inferred that the templates, time zones, one-time plans, Agent management entries, or adjacent pages of the reference project must be migrated in. Only the limited behavior baseline explicitly specified by the user is subject to complete retention investigation.
Evidence records are used to prevent incorrect writing and for review. When the source description is not precise enough, correct the record first; only when it causes a real product fork can entry into design be blocked.

3. 用流程图校正复杂产品理解

3. Correct Complex Product Understanding with Flowcharts

需求包含独立触发源、后台或定时运行、Agent/Skill/调度器协作、共享数据或多个局部参考实现时，完整读取并执行 复杂产品理解。
复杂需求必须用流程图表达核心产品关系。图的完成标准是读者能够看清：谁触发、谁执行、哪些流程彼此独立、流程之间是控制关系还是只共享数据，以及用户最后看到什么。图是防止理解错误的工具，不因缺少指定符号、逐边类型或额外技术图而单独判定需求失败。
如果新证据证明执行主体、触发关系、独立流程划分或控制关系理解错误，撤回由错误模型派生的结论并重画受影响流程。不要只修改用户指出的一句话后继续沿用旧结论。图形修复后仍用设计阻塞型产品分叉判断能否进入设计。
When requirements include independent trigger sources, background or scheduled operations, Agent/Skill/scheduler collaboration, shared data, or multiple partial reference implementations, fully read and execute Complex Product Modeling.
Complex requirements must use flowcharts to express core product relationships. The completion standard of the diagram is that readers can clearly see: who triggers, who executes, which processes are independent of each other, whether the relationship between processes is a control relationship or only shared data, and what users finally see. The diagram is a tool to prevent understanding errors, and the requirement will not be judged to fail solely due to the lack of specified symbols, edge-by-edge types, or additional technical diagrams.
If new evidence proves that the understanding of the execution subject, trigger relationship, independent process division, or control relationship is wrong, withdraw the conclusions derived from the wrong model and redraw the affected processes. Do not only modify the sentence pointed out by the user and continue to use the old conclusions. After the diagram is fixed, still use design-blocking product forks to judge whether it can enter the design phase.

4. 走查既有与参照用户流程

4. Walk Through Existing and Reference User Processes

改造已有能力、要求“继续可用/保持一致”，或用户指定现有产品作为行为基线时，先走查最接近的真实用户流程，并按需形成 
现状与参照流程.md
。需求阶段记录用户可见基线：
  • 入口以及用户如何到达；
  • 列表或选择界面展示什么；
  • 详情展示什么业务对象；
  • 用户能执行什么操作，操作针对什么对象；
  • 权限如何改变可见性或可操作性；
  • 操作中的反馈、完成结果和操作后的可见状态。
这项走查属于需求阶段，因为它确定保留或改变的用户行为。页面组件、接口、数据和权限校验的技术落点属于设计阶段。
正文不能只写“继续可用”或“与参考一致”。应概括主要入口、场景、操作和结果，使正文可以独立理解；走查记录保存更细的基线证据。
视觉需求只需确定参考对象与版本、适用页面或能力、还原程度和已知行为差异。固定源码、页面或截图本身可以构成 1:1 基线，不要求用户在需求阶段用文字重新描述像素；组件映射、设计 token、原型和逐屏比较进入设计与验证。
When transforming existing capabilities, requiring "continue to be available/keep consistent", or the user specifies an existing product as a behavior baseline, first walk through the closest real user process, and form 
现状与参照流程.md
as needed. Record user-visible baselines in the requirement phase:
  • Entries and how users reach them;
  • What is displayed in the list or selection interface;
  • What business objects are displayed in the details;
  • What operations users can perform and what objects the operations target;
  • How permissions change visibility or operability;
  • Feedback during operations, completion results, and visible status after operations.
This walkthrough belongs to the requirement phase because it determines the user behaviors to be retained or changed. The technical implementation of page components, interfaces, data, and permission verification belongs to the design phase.
The main text cannot only write "continue to be available" or "consistent with reference". It should summarize the main entries, scenarios, operations, and results so that the main text can be understood independently; the walkthrough records save more detailed baseline evidence.
Visual requirements only need to determine the reference object and version, applicable pages or capabilities, restoration degree, and known behavior differences. Fixed source code, pages, or screenshots can constitute a 1:1 baseline, and users are not required to re-describe pixels in words during the requirement phase; component mapping, design tokens, prototypes, and screen-by-screen comparisons enter the design and verification phase.

5. 执行设计阻塞型产品分叉测试

5. Execute Design-blocking Product Fork Test

对每个疑似缺口依次判断：
  1. 正文其他位置或已确认材料是否已经回答？如果是，修正文表达或停止重复讨论。
  2. 项目或参考实现是否能够回答？如果是，先调查；不要问用户事实题。
  3. 是否只影响技术做法、文档形式或验证方法？如果是，记录为设计输入或整理问题。
  4. 差异是否直接改变主要用户目标、核心旅程、首期边界、明确规则或承诺结果？如果只改变内部判断、数据投影或实现策略，交给设计。
  5. 设计者能否在不改变产品承诺的前提下选择并在方案中明确？如果能，不得把它列为需求问题。
  6. 只有剩余答案会形成彼此排斥的产品方向，并且不先决定就无法形成自洽方案时，才记录为需求分叉。
对已经看似“解决”的产品分叉再检查一次决定来源。若答案只来自参考项目存在该功能、agent 偏好、审查建议或技术风险，该分叉仍未被合法解决，不能因为正文已经选择了一边就判定通过。
缺少一句正文不等于缺少产品决定。发现正文漏写已有结论时直接补齐；发现设计尚未展开时交给设计；发现与目标无关的防御性问题时丢弃。
不要因为 agent 认为拆期更稳或实现更容易，就自行拆分一个已经闭合的用户流程。只有拆分后的每期仍形成可用闭环，并且存在真实优先级、依赖、风险或成本依据时，才把分期作为产品候选。
Judge each suspected gap in turn:
  1. Has it been answered in other parts of the main text or confirmed materials? If yes, correct the main text expression or stop repeated discussions.
  2. Can it be answered by the project or reference implementation? If yes, investigate first; do not ask users factual questions.
  3. Does it only affect technical practices, document forms, or verification methods? If yes, record it as a design input or sorting issue.
  4. Does the difference directly change the main user goals, core journey, first-phase boundaries, clear rules, or promised results? If it only changes internal judgments, data projection, or implementation strategies, hand it over to design.
  5. Can designers choose and clarify it in the solution without changing the product commitment? If yes, it shall not be listed as a requirement issue.
  6. Only when the remaining answers will form mutually exclusive product directions and a self-consistent solution cannot be formed without prior decision, record it as a requirement fork.
Check the source of decision again for product forks that seem to have been "resolved". If the answer only comes from the reference project having this function, agent preference, review suggestion, or technical risk, the fork has not been legally resolved, and it cannot be judged as passed just because the main text has chosen one side.
The lack of a sentence in the main text does not mean the lack of a product decision. When it is found that the main text misses a concluded decision, directly complete it; when it is found that design has not yet started, hand it over to design; when it is found that defensive issues irrelevant to the target, discard them.
Do not split a closed user process on your own just because the agent thinks splitting phases is more stable or easier to implement. Only when each phase after splitting still forms a usable closed loop, and there are real priorities, dependencies, risks, or cost basis, can phase splitting be regarded as a product candidate.

6. 澄清真实的设计阻塞型产品分叉

6. Clarify Real Design-blocking Product Forks

只询问用户必须决定的设计阻塞型产品分叉。默认将互不依赖的问题合并为一轮 2–5 个编号问题；确实只有一个分叉，或当前答案会改变后续问题时，可以只问一个。
每个问题都要：
  • 先说明已经查清的事实和当前理解；
  • 给出仍成立的少量产品答案；
  • 说明每个答案会怎样改变用户体验、范围、规则或结果；
  • 使用产品语言，不要求用户判断技术契约；
  • 允许用户直接纠正问题前提。
不要询问实现参数、表结构、接口字段、状态机设计、测试方法、已有基线能够回答的现成交互，或“是否还有其他要求”一类无边界问题。
Only ask users about design-blocking product forks that must be decided. By default, merge independent questions into a round of 2–5 numbered questions; if there is indeed only one fork, or the current answer will change subsequent questions, only one question can be asked.
Each question must:
  • First explain the facts that have been clarified and current understanding;
  • Give a small number of valid product answers;
  • Explain how each answer will change user experience, scope, rules, or results;
  • Use product language, and do not require users to judge technical contracts;
  • Allow users to directly correct the premise of the question.
Do not ask about implementation parameters, table structures, interface fields, state machine design, testing methods, existing interactions that can be answered by existing baselines, or open-ended questions such as "are there any other requirements".

7. 编写需求正文

7. Write Requirement Main Text

只把已经明确的产品结论写入正文，把调研过程、讨论历史和细粒度证据放入同名二级目录。复杂需求可以采用以下阅读顺序，但按实际内容合并章节，不为模板保留空项：
  1. 产品目标与用户；
  2. 用户故事和核心旅程；
  3. 核心产品流程图；
  4. 现状基线与行为差异；
  5. 主要功能、业务对象和用户可见规则；
  6. 首期范围与明确排除项；
  7. 可观察结果。
正文优先使用产品和业务语言。实现名词确实有助于定位已决定能力时可以保留，但不要展开类、接口、表、路由、组件、事件或内部算法。正文中存在少量设计输入不自动使需求无效；写作任务中将其移入技术方案待办或二级材料即可。
技术风险可能要求产品承诺一个用户可见结果，但不能把 agent 选定的解决机制冒充成需求。例如需求可以规定“并发执行不能破坏工作区，并向用户说明未执行原因”，不能未经决定就规定按目录包含关系加锁、排队或跳过。具体门禁对象、锁、队列和恢复算法进入设计。
用户要求“列出所有决定与理由”时，只盘点实际已经存在的决定，并分别列出决定来源、理由和影响。把尚未决定的方向单列为候选，把实现问题单列为设计输入；这项要求不授权 agent 为每个来源事实作出新决定，也不要求制造固定数量或连续编号的决定。
首次创建正文时按项目规范标记状态；没有规范时标为“草稿”。需求含义发生变化时立即恢复为草稿。只有在当前候选版本已经向用户呈现之后，用户又明确接受该版本，才能标记为已确认；确认依据必须来自这次呈现之后的用户消息。用户说“修改”“修正”“更新”“继续”“列出决定”“返回需求阶段”或指出错误，都不是对修改后内容的确认。同一回合中新建或实质改写的候选版本不得由 agent 自行标记为已确认。
用户尚未正式认可不等于内容不清晰：可以报告“需求语义已清晰，可以进入设计；文档仍待正式确认”。用户明确要求进入设计，只有在它清楚指向此前已经呈现且之后未再改变的候选版本时，才可以作为交接确认；不能确认该消息之后 agent 新增或改写的内容。确认时在变更记录中写明实际确认依据，不得补写不存在的“用户正式确认”。
需求含义变化时追加简短变更记录。不要在正文写审查过程，也不要让正文依赖二级材料才能理解。
Only write clearly confirmed product conclusions into the main text, and put research processes, discussion history, and fine-grained evidence into the same-named secondary directory. Complex requirements can adopt the following reading order, but merge chapters according to actual content and do not keep empty items for templates:
  1. Product goals and users;
  2. User stories and core journeys;
  3. Core product flowcharts;
  4. Current baseline and behavior differences;
  5. Main functions, business objects, and user-visible rules;
  6. First-phase scope and clearly excluded items;
  7. Observable results.
The main text prioritizes product and business language. Implementation terms can be retained if they really help locate decided capabilities, but do not expand on classes, interfaces, tables, routes, components, events, or internal algorithms. The presence of a small amount of design input in the main text does not automatically invalidate the requirements; during writing, move them to technical solution to-do items or secondary materials.
Technical risks may require the product to promise a user-visible result, but cannot pass off the solution mechanism selected by the agent as a requirement. For example, requirements can specify "concurrent execution cannot damage the workspace, and users shall be informed of the reason for non-execution", but cannot specify locking, queuing, or skipping according to directory inclusion relationships without decision. Specific access control objects, locks, queues, and recovery algorithms enter the design phase.
When the user requests "list all decisions and reasons", only inventory the decisions that actually exist, and list the source of decision, reason, and impact separately. List undecided directions as candidates, and list implementation issues as design inputs; this request does not authorize the agent to make new decisions for each source fact, nor does it require creating a fixed number or consecutively numbered decisions.
Mark the status according to project specifications when creating the main text for the first time; mark it as "Draft" if there is no specification. Immediately restore it to draft when the requirement meaning changes. Only after the current candidate version has been presented to the user and the user explicitly accepts the version can it be marked as confirmed; the confirmation basis must come from the user's message after this presentation. User statements such as "modify", "correct", "update", "continue", "list decisions", "return to requirement phase", or pointing out errors are not confirmation of the modified content. Candidate versions newly created or substantially rewritten in the same round cannot be marked as confirmed by the agent on its own.
The fact that the user has not formally approved does not mean the content is unclear: you can report "The requirement semantics are clear and can enter the design phase; the document is still pending formal confirmation". When the user explicitly requests to enter the design phase, it can only be regarded as handover confirmation if it clearly points to the candidate version that was presented earlier and has not been changed since then; it cannot confirm the content added or rewritten by the agent after this message. When confirming, write the actual confirmation basis in the change record, and do not fill in non-existent "formal user confirmation".
Add a brief change record when the requirement meaning changes. Do not write the review process in the main text, and do not make the main text dependent on secondary materials to be understood.

8. 自检并给出明确结论

8. Self-inspect and Give Clear Conclusions

交付前由 agent 自检，不把发现遗漏的责任交给用户：
  • 产品视角：问题、用户、价值、范围和主要体验能否一致理解；
  • 开发视角：能否在不猜测产品行为的前提下进入技术设计；
  • 测试视角：能否从正文得到主要场景和用户可见结果；
  • 用户旅程：主要入口是否能走到完成、失败或恢复后的可见结果；
  • 参考差异：沿用、改变和排除的用户行为是否明确。
  • 决定来源：本次新增或改变的每条规范性产品表述是否都有用户表达、已确认目标基线、项目硬约束或必然直接结果作为来源；不得只靠参考事实或 agent 理由。
  • 状态一致性：正文、需求地图、审查记录、变更记录和最终回复是否对草稿/已确认给出同一答案，且已确认状态存在真实的后续用户依据。
自行修复事实遗漏、正文表达和交叉矛盾；把实现问题交给设计。不要为追求“绝对完整”穷举低价值异常，也不要规定必须发现多少问题或审查多少轮。
最后必须给出以下一种结论：
  • 可以进入设计：产品目标、主要旅程、范围和结果已经明确，且不存在未解决的设计阻塞型产品分叉；
  • 尚不能进入设计：列出仍存在的设计阻塞型产品分叉、不同方向造成的产品影响，以及为什么不能留给设计；
  • 需要先调查：说明缺少什么事实、将从哪里查证；不能把调查任务转给用户。
文档格式缺陷、图表形式、证据记录不完整或设计细节待定可以作为非阻塞改进项报告，但不能与产品分叉混在一起，也不能用它们得出“需求不清晰”。
Self-inspect by the agent before delivery, and do not transfer the responsibility of finding omissions to the user:
  • Product perspective: Can the problem, users, value, scope, and main experience be consistently understood;
  • Development perspective: Can technical design be entered without guessing product behaviors;
  • Testing perspective: Can main scenarios and user-visible results be obtained from the main text;
  • User journey: Can the main entry lead to visible results after completion, failure, or recovery;
  • Reference differences: Are the user behaviors to be followed, changed, and excluded clear.
  • Source of decision: Does each normative product statement added or changed this time have a source such as user expression, confirmed target baseline, project hard constraint, or inevitable direct result; do not rely solely on reference facts or agent reasons.
  • Status consistency: Do the main text, requirement map, review records, change records, and final reply give the same answer for draft/confirmed, and does the confirmed status have real subsequent user basis.
Fix factual omissions, main text expressions, and cross-contradictions on your own; hand over implementation issues to design. Do not exhaust low-value exceptions in pursuit of "absolute completeness", nor require a certain number of problems to be found or a certain number of review rounds.
Finally, one of the following conclusions must be given:
  • Ready to enter design: Product goals, main journeys, scope, and results are clear, and there are no unresolved design-blocking product forks;
  • Not ready to enter design: List the remaining design-blocking product forks, product impacts caused by different directions, and why they cannot be left to design;
  • Need investigation first: Explain what facts are missing and where to verify them; do not transfer the investigation task to the user.
Document format defects, chart forms, incomplete evidence records, or pending design details can be reported as non-blocking improvement items, but cannot be mixed with product forks, nor can they be used to conclude "requirements are unclear".

质疑与纠错

Questioning and Error Correction

用户引用正文并质疑来源、指出理解错误或询问为什么没有调查参考项目时，先定位受影响结论并停止扩写。核实事实，区分参考行为和目标采用决定，再按影响范围修正文档。
先建立纠错依赖闭包：撤销错误结论，追踪并撤销只由它派生的正文、图、状态、审查和下游结论；保留没有依赖该错误的已确认内容。新发现但不在依赖闭包内的参考能力只记录为证据，不得借纠错自动扩大产品范围。用户明确反对“唯一任务”时，恢复通用多任务边界及评估作为其中一种任务的直接结果；这仍不等于完整迁入参考产品所有 Automations 能力。
质疑本身不自动形成新的产品决定，也不授权扩大参考范围。用户只要求解释时，只说明原因、影响和正确理解，不修改文件。
纠错完成后先重新执行产品决定来源门禁，再执行设计阻塞型产品分叉测试。含义发生变化时保持草稿，等待用户看到修订版后的明确确认。不能因为用户已经确认过旧版本，就把后来发现的需求缺陷归责于用户。
When the user quotes the main text and questions the source, points out understanding errors, or asks why the reference project was not investigated, first locate the affected conclusion and stop expanding. Verify facts, distinguish reference behaviors and target adoption decisions, then revise the document according to the scope of impact.
First establish a error correction dependency closure: Revoke wrong conclusions, track and revoke main text, diagrams, status, reviews, and downstream conclusions derived only from it; retain confirmed content that does not depend on this error. Newly discovered reference capabilities not within the dependency closure are only recorded as evidence, and the product scope shall not be automatically expanded under the pretext of error correction. When the user explicitly opposes "only one task", restore the general multi-task boundary and evaluation as a direct result of one of the tasks; this still does not mean fully migrating all Automations capabilities of the reference product.
Questioning itself does not automatically form a new product decision, nor does it authorize expanding the reference scope. When the user only requests an explanation, only explain the reason, impact, and correct understanding, and do not modify the file.
After error correction, first re-execute the source of product decision admission criteria, then execute the design-blocking product fork test. Restore to draft when the meaning changes, and wait for the user's explicit acceptance after seeing the revised version. Do not attribute later-discovered requirement defects to the user just because the user has confirmed the old version.

完成标准

Completion Standards

需求阶段完成的标准是：
  • 产品目标、主要用户和价值闭环明确；
  • 主要用户旅程、首期范围和用户可观察结果能够一致理解；
  • 复杂流程的执行主体、独立关系和结果没有被误解；
  • 受影响的既有或参照用户流程已经走查，重要偏离已经决定；
  • 本次新增或修改的规范性产品表述都有合法决定来源，参考事实、审查意见和 agent 推荐没有被自动晋级为目标需求；
  • 当前没有未解决的设计阻塞型产品分叉；
  • agent 已完成事实核对和自检，用户无需替 agent 找遗漏。
达到这些条件即可进入设计。需求阶段不需要先完成技术架构、内部数据模型、完整状态机、原型、测试用例或实现计划。
已确认版本发生任何产品含义变化时恢复为草稿。只有用户在修订版呈现后的后续消息中明确接受，才能重新确认；交付前必须核对文件实际状态与最终回复一致。用户确认后发现 agent 本应通过调查或自检发现的需求缺陷，重新打开需求并修复；不得以用户此前确认作为免责依据。
The completion standards for the requirement phase are:
  • Product goals, main users, and value closed-loop are clear;
  • Main user journeys, first-phase scope, and user-observable results can be consistently understood;
  • There is no misunderstanding of the execution subject, independent relationship, and results of complex processes;
  • Affected existing or reference user processes have been walked through, and important deviations have been decided;
  • Each normative product statement added or modified this time has a legal source of decision, and reference facts, review opinions, and agent recommendations have not been automatically promoted to target requirements;
  • There are no unresolved design-blocking product forks currently;
  • The agent has completed fact checking and self-inspection, and the user does not need to find omissions for the agent.
When these conditions are met, you can enter the design phase. The requirement phase does not need to complete technical architecture, internal data models, complete state machines, prototypes, test cases, or implementation plans first.
Restore to draft when any product meaning change occurs in the confirmed version. Only when the user explicitly accepts it in subsequent messages after the revised version is presented can it be re-confirmed; before delivery, you must check that the actual file status is consistent with the final reply. If requirement defects that the agent should have found through investigation or self-inspection are discovered after user confirmation, reopen the requirements and fix them; do not use the user's previous confirmation as a disclaimer.