01 · 业务建模与规则设计
参与跨子公司调研、流程设计与数据归纳。系统采用固定程序与算法进行流程预测，AI 主要提供工作建议。
集团工程管理系统 ↗RULES → WORKFLOW → AGENT ORCHESTRATION
我的 AI 产品工作流。
从业务规则设计到 Agent 协作，逐步将 AI 用于需求、研发与上线运营。
WORKING PRINCIPLES
协作原则。
持续维护上下文
将客户诉求、研发约束与评审结论写入项目。结果偏离预期时，先检查背景是否完整。
控制需求范围
评估 AI 提出的方案，区分当前必需与后续迭代，明确每项关键设计的理由。
先判断，再执行
先确定问题、目标与验收标准，再进入生成和实施。
HARNESS / PROMPT / SKILL / AGENT / HUMAN
工具与协作分工。
执行环境 · Harness
管理上下文、工具、任务状态与检查步骤，支持 AI 持续参与项目。
提示词 · Prompt
明确目标、材料、输出与验收要求，标注待确认事项。
可复用技能 · Skill
保存常用流程、格式与检查要求，在同类任务中复用和迭代。
智能体分工 · Agent
按任务安排 Agent，明确输入、输出与交接条件，及时处理执行偏差。
评估交付质量
检查事实、引用、格式及关联文档的一致性。
人负责关键决策
确认业务目标、需求取舍与发布。将可重复、可验证的任务逐步交给 Agent。
PRODUCT LIFECYCLE
从需求定义到上线迭代。
按十个阶段展示工作内容、AI 任务、我的判断与交付内容。
STAGE 01 / 10
项目初始化
工作内容
整理产品介绍、历史 PRD、截图与设计规范，区分当前事实、未来规划和未落地讨论。
AI 任务
梳理产品材料、已知事实与待确认问题。
我的判断
AI 整理已知事实与待确认问题。我确认产品现状、协作规则与修改范围。
交付内容
产品现状、材料登记、规则与待确认清单
1 / 10
DECISIONS IN PRACTICE
需求与设计取舍。
端口修改的范围控制
AI 为端口修改补充了批量处理、部分成功和逐条失败反馈。我按必要性与实现成本评估这些建议，区分当期需求与后续迭代。
20 个需求包，百余个需求点
在一个版本中，与 AI 澄清 20 个需求包、百余个需求点。我逐项确认关键设计及其依据。
原型先对齐约束
以现有页面、组件和交互规范约束原型，检查其与原产品的视觉和操作一致性。
决策保留理由
记录评审删改、实现调整的时间与原因，为后续版本保留决策依据。
PROJECT FILES
统一管理产品材料与版本。
统一管理材料、需求与版本。以 Markdown 维护内容，按需生成 Word、PDF 和 PPT。
00-rules/规则和模板01-inputs/原始材料与来源登记02-product/稳定产品事实与术语03-planning/问题空间、模块地图与决策04-requirement-pool/候选需求与唯一状态记录05-requirements/独立需求工作包06-versions/版本目标、范围与里程碑07-reviews/评审、验收和复盘90-assets/共享演示和原型资产99-archive/关闭或过期材料统一维护产品事实
登记材料来源，区分事实、推断与待确认事项。同类信息集中维护，其他文档引用。
需求与版本分开管理
在需求池中维护状态与优先级。在版本清单中确定交付范围。已批准需求发生实质变化时，重新评审。
验证上线状态
上线检查通过并留下记录后，将状态更新为 released。
确认正式变更
Agent 提出变更及影响范围，经负责人确认后更新正式材料与状态。
查看项目初始化说明
复制以下说明，交给 Agent 在空项目中执行。
在空项目根目录中建立产品工作空间。 1. 目录 00-rules/、01-inputs/、02-product/、03-planning/、04-requirement-pool/、05-requirements/、06-versions/、07-reviews/、90-assets/、99-archive/。 每个目录创建 README.md，说明职责和入口。 2. .gitignore .DS_Store ~$*.docx ~$*.xlsx ~$*.pptx 3. 核心规则文件 00-rules/naming-and-structure.md：说明各目录职责。Markdown 文件名使用英文小写，以连字符分隔（kebab-case）。日期材料命名为 YYYY-MM-DD-主题。需求命名为 req-0001-short-name。版本命名为 v主版本.次版本。 00-rules/source-of-truth.md：每类信息只有一个维护位置，其他地方引用，不复制维护。 00-rules/status-and-gates.md：candidate → collecting → analyzing → defined → reviewing → approved → developing → validating → released → closed。起步可简化为 candidate → analyzing → defined → approved → released → closed。 状态只在需求池维护。approved 后实质变化，记录变更并回到 reviewing。released 必须有真实上线验证证据。 00-rules/product-workflow.md：原始输入 → 产品认知与规划 → 需求池 → 单需求定义 → 原型与 PRD → 版本承诺 → 开发验收 → 上线验证 → 复盘。 先登记原始输入。确认阶段结论后再保存。每个需求必须能独立定义、评审、开发和验收。 4. 根目录入口 README.md：产品名称、工作空间用途、当前阶段、规则及各目录入口。初始化时注明尚未启动正式版本。 AGENTS.md：索引上述规则，并记录协作边界。 先登记输入，再形成方案。历史材料不天然等于正式需求。 产品判断引用来源，标记已观察、推断、待确认、未覆盖。 Markdown 为长期事实源。Word、PDF 等为已确认内容的交付产物。 新增、修改或删除文件前，说明问题判断和影响范围。取得负责人确认后再执行。 保留来源引用、待确认事项与未覆盖范围。 未经确认不得把草稿标为已批准或推进正式状态。 密钥、Token、密码不进入代码、文档和 Git 历史。 5. 输入来源登记 01-inputs/source-register.md 字段：来源 ID、日期、材料、类型、提供方、项目内位置、适用范围、当前处理状态。 原始材料不静默改写。新版本新增记录并保留旧版本。正式需求引用来源 ID。 6. 需求池 04-requirement-pool/requirement-pool.md 字段：需求 ID、需求名称、来源、所属模块、状态、优先级、负责人、目标版本、前置依赖、工作包。 来源填写 SRC-XXXX。状态遵循规则文件。优先级 P0/P1/P2/P3，说明依据。 目标版本是当前计划，版本承诺以 06-versions/<version>/scope.md 为准。
IN PRACTICE
项目中的 AI 应用。
PROJECT DELIVERY DOCUMENTATION
成套文档的组织与交付。
根据智慧城市项目的评审经验，将需求、设计、测试与部署文档的编写和检查要求整理为 SOP、模板与 Skill。
- 需求规格
- 概要与详细设计
- 实施
- 测试方案、用例与报告
- 部署与使用手册
- 培训与试运行
- 总结
生成之前
确认合同范围，统一术语，整理材料并规划章节。
交付之前
核对需求、设计、测试与手册的一致性，同步更新关联内容。