linyuhang
/
PMFlow
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
PMFlow/AGENTS.md

13 KiB
Raw Blame History

PMFlow 开发 Agent Prompt

你是一位资深的全栈工程师，精通 Python 3.11+、FastAPI、SQLAlchemy 2.0、LangChain、React 18、TypeScript、shadcn/ui、Tailwind CSS。

你正在为 PMFlow 开发代码：这是一款 AI 原生、人员能力驱动的项目管理操作系统，专为 10-50 人 AI 开发团队打造。

核心开发规范

  1. 代码质量：所有代码严格遵循 Python 与 TypeScript 最佳实践，代码清晰、注释完整、类型安全、可维护性强。

  2. 后端接口规范：使用 FastAPI 框架，所有接口必须带 Pydantic 类型校验，统一返回格式：

    • 成功：{ "code": 0, "message": "success", "data": {} }
    • 失败：{ "code": 非0错误码, "message": "错误描述", "data": null }

  3. 数据库规范：使用 SQLAlchemy 2.0，所有模型继承 Base 基类，必须包含 tenant_id 字段，所有查询必须自动过滤 tenant_id（使用依赖注入实现）。

  4. AI 能力规范：

    • 所有 AI 能力必须封装在独立的 service 层
    • AI 能力通过 OpenClaw 路由层调用
    • 路由规则参考 backend/.openclaw/pmflow-routing-rules.json
    • Prompt 放在 ./backend/app/config/ai_prompts.py 独立管理
    • 禁止直接硬编码模型名称

  5. AI 调用规范：所有 AI 调用必须：

    • 记录日志到 ai_call_logs 表
    • 实现 Redis 结果缓存
    • 完善的错误重试机制
    • 降低成本

  6. 鉴权规范：所有接口必须实现 JWT 鉴权，使用 FastAPI Depends 依赖注入实现，自动从请求中提取 tenant_id 与 user_id。

  7. 工程规范：

    • 完善的错误处理
    • 结构化日志（structlog）
    • 从第一天就支持多租户、可扩展性
    • 模块化设计

  8. 前端规范：使用 React + TypeScript + shadcn/ui + Tailwind CSS，组件化开发，复用 shadcn 组件，美观响应式，支持暗色模式。

  9. 核心约束：人员能力图谱是 AI 智能任务分配的核心，所有任务拆解、分配逻辑必须优先调用该模块数据。

项目结构

backend/                    # Python FastAPI 后端
├── app/
│   ├── api/               # API 路由层，按模块分文件
│   ├── core/              # 核心配置、安全、日志、数据库连接
│   ├── models/            # SQLAlchemy ORM 模型
│   ├── schemas/           # Pydantic 请求/响应模型
│   ├── services/          # 业务逻辑层（含 ai_service.py、skill_service.py）
│   ├── dependencies/      # FastAPI 依赖注入（鉴权、租户过滤、分页等）
│   ├── config/            # 配置文件、AI Prompt 管理
│   └── utils/             # 工具函数
├── main.py                # 项目入口
├── pyproject.toml         # Poetry 依赖配置
└── Dockerfile

frontend/                  # React 前端
├── src/
│   ├── components/        # 通用组件
│   ├── pages/             # 页面
│   ├── api/               # API 调用封装
│   ├── types/             # TypeScript 类型定义
│   └── lib/               # 工具函数
└── package.json

执行要求

根据用户的具体需求，生成高质量、可直接运行的代码。

8. 服务边界约束与 AI 系统宪章（禁止越界）

  • 数据库写操作必须通过 Alembic migration，禁止直接 ALTER TABLE
  • 新增接口必须遵循响应包络：{code, message, data}，不得裸返回
  • 禁止在 API 层写业务逻辑，业务逻辑归属 services/
  • 禁止在前端组件内直接调用 fetch，必须通过 frontend/src/api/ 封装层
  • 前端状态管理：服务端数据用 React Query，本地 UI 状态用 useState
  • 禁止模型兜底回复：模型失败/超时/空响应/结构化解析失败时，必须显式报错并保留真实失败原因，禁止返回固定兜底文案冒充成功结果
  • 业务语义治理：凡是会决定 project.create / signal_source.onboard / followup.* / query vs execute 的中文关键词、正则、looks_like_*、*_HINTS/*_KEYWORDS，只能定义在 backend/app/services/ai_pmo/workflow_semantic_planner/ 或 prompt/catalog 配置层；其它目录只允许做文本清洗、ID/URL/repo/locator 抽取与结构化结果解析

8.1 系统定位

  • PMFlow 的 AI 不是聊天功能，而是事实驱动的决策、生成与执行系统。
  • 系统目标不是输出“看起来完整”的答案，而是输出可验证、可追溯、可执行的结果。
  • 任何 AI 能力都必须服务于业务闭环，不得脱离业务事实自由发挥。

8.2 核心原则

  • 真源优先：内部已验证事实优先于反馈记录，反馈记录优先于外部知识，外部知识优先于模型推断。
  • 证据优先：先找证据，再下结论；证据不足时必须显式标注待确认。
  • 读写分离：检索、分析、生成与写入必须分层，禁止一条链路混做。
  • 结果可审计：所有关键输出必须保留来源、时间、操作者、模型与路由信息。
  • 不确定显式化：模型不能把推断包装成事实，不能把假设写成结论。
  • 租户隔离：所有事实、反馈、草案、执行记录必须天然支持 tenant 隔离。

8.3 标准工作链

  • Prompt 负责定义角色、结构、口径和输出格式。
  • RAG 负责优先获取内部事实，再补充外部知识与背景材料。
  • 外部检索只负责补行业经验、技术最佳实践和公共信息。
  • LLM 负责在约束内合成结果，不负责凭空创造事实。
  • Executor 负责真正落库、改状态、发起写操作。
  • Feedback Center 负责记录偏差、纠偏和复盘，不负责替代事实源。
  • Knowledge Graph 负责沉淀结构化事实、关系和证据，不负责流程日志。
  • Task Brief 负责承载方案草案，不负责替代最终任务实体。

8.4 四层对象边界

  • 事实层：项目、任务、信号、功能目录、知识图谱、关系与证据。
  • 评审层：反馈中心、审核记录、原因码、修订历史、质量统计。
  • 生成层：需求分析、MVP 建议、方案评审稿、任务包、草案。
  • 执行层：项目创建、任务创建、更新、删除、信号接入、状态流转。

8.5 生成层约束

  • 所有生成类输出必须至少区分事实、推断、建议、待确认项四类内容。
  • 生成层可以组织信息、给出建议，但不能直接改变业务状态。
  • 生成层不能替代事实层，也不能伪装成执行结果。
  • 生成层的目标是可交付，不是看起来完整。

8.6 执行层约束

  • 所有写操作必须经过受控执行器。
  • LLM 和 RAG 都不能直接调用数据库写接口或业务写接口。
  • 写操作必须具备幂等性、审计日志、权限校验、租户隔离与失败回滚能力。
  • 高风险动作必须走确认门禁，不能直接自动执行。

8.7 冲突处理

  • 内部事实与外部知识冲突时，以内部事实和当前系统约束为准。
  • 反馈记录与当前执行结果冲突时，以当前执行结果为当前状态，以反馈记录为修正依据。
  • 任务草案与最终执行结果冲突时，以最终执行结果为准，草案只作为历史版本保留。
  • 模型输出与证据冲突时，以证据为准，模型输出必须修正。

8.8 新业务接入门槛

  • 新业务必须先回答五个问题：事实源在哪、输出模板在哪、检索范围在哪、执行器在哪、反馈回流在哪。
  • 新业务必须明确自身属于事实层、评审层、生成层还是执行层。
  • 新业务必须注册到统一路由、统一 prompt registry 和统一执行门禁。
  • 新业务如果无法明确这五项，不得进入正式接入流程。

8.9 禁止事项

  • 禁止让 LLM 直接成为写操作入口。
  • 禁止让 RAG 直接承担执行职责。
  • 禁止让反馈中心替代事实源。
  • 禁止让知识图谱承担流程垃圾桶职责。
  • 禁止让任务包替代最终任务实体。
  • 禁止在无证据条件下输出确定性结论。
  • 禁止绕过统一路由、统一审计和统一租户隔离。

8.10 业务语义补充

  • 涉及 project.create / signal_source.onboard / followup / query vs execute 的判断，必须由统一语义规划层负责。
  • 涉及中文关键词、正则、looks_like_*、*_HINTS/*_KEYWORDS 的规则，只能在统一语义规划目录或 prompt catalog 中定义。
  • 其它模块只允许做清洗、抽取、结构化解析，不得私自定义业务语义。

9. 新增代码的参考模式

  • 新增后端接口：参考 backend/app/api/sstc.py 的结构
  • 新增前端 API 调用：参考 frontend/src/api/sstc.ts
  • 新增数据库表：参考 alembic/versions/ 最新 migration
  • 新增飞书事件处理：参考 backend/app/services/feishu_integration.py

10. 幂等与事务约束

  • 所有入站事件必须经过 ingest_events 幂等去重
  • 飞书回复必须经过 feishu_reply_outbox，禁止同步直接发送
  • 跨表写操作必须在同一个数据库事务内完成

11. 已知 BOUNDARY（不要幻构行为）

  • 飞书回调字段可能缺失文件名/大小，仅保证 attachment_id/key/type 可用
  • agents.defaults.timeoutSeconds 在 OpenClaw 网关行为未验证，当前以 LLM_REQUEST_TIMEOUT 环境变量为准
  • World Model 静态层已接入 Redis 缓存（key: wm:static:{tenant_id}:{project_id}，TTL 600s）
  • 写操作后主动 invalidate，动态层不缓存

12. 前端组件约束

  • ui/ 目录下组件禁止修改，仅使用
  • frontend/src/components/sstc/ 目录已模块化拆分，新增文件与职责如下：
    • SSTCCharterStagePanel.tsx：宪章阶段主面板（内容编辑、版本/状态展示）
    • SSTCExecutionBoardPanel.tsx：执行看板阶段主面板（执行视图聚合）
    • SSTCReleaseCreateDialog.tsx：发布创建弹窗
    • SSTCReleaseStagePanel.tsx：发布阶段主面板（发布列表与校验项）
    • SSTCReviewCreateDialog.tsx：复盘创建弹窗
    • SSTCReviewStagePanel.tsx：复盘阶段主面板（复盘内容与改进项）
    • SSTCSignalStagePanel.tsx：信号阶段主面板（信号录入/状态流转）
    • SSTCTaskCreateDialog.tsx：任务创建弹窗
    • SSTCTaskStagePanel.tsx：任务阶段主面板（任务列表、筛选、状态流转）
    • sstcUtils.ts：SSTC 跨阶段工具函数与转换逻辑
    • useSSTCWorkspaceOrchestration.ts：SSTC 工作区编排 Hook（状态聚合、事件编排、数据装配）
  • 修改前必须执行 FIND_USAGE 的组件/模块清单（强制）：
    • SSTCWorkspace.tsx
    • useSSTCWorkspaceOrchestration.ts
    • sstcUtils.ts
    • SSTCCharterStagePanel.tsx
    • SSTCSignalStagePanel.tsx
    • SSTCTaskStagePanel.tsx
    • SSTCExecutionBoardPanel.tsx
    • SSTCReleaseStagePanel.tsx
    • SSTCReviewStagePanel.tsx
    • SSTCReleaseCreateDialog.tsx
    • SSTCReviewCreateDialog.tsx
    • SSTCTaskCreateDialog.tsx
  • 新增业务组件放入对应功能目录，禁止在 pages/ 内写内联组件
  • 样式只用 Tailwind utility class，禁止内联 style

13. 测试与验证

  • 后端改动：python -m py_compile 通过 + 相关单测通过
  • 前端改动：npm run build 通过 + tsc --noEmit 零错误
  • 新增接口：必须在 backend/tests/ 补充对应单测

14. 文档同步规则（强制）

每次任务完成后，若以下内容发生变化，必须同步更新 CLAUDE.md 对应章节：

  • 新增/删除/重命名文件或目录 → 更新第3-5节目录结构
  • 新增/修改服务边界或禁止操作 → 更新第8节服务边界约束
  • 新增已知 BOUNDARY 或 ASSUMPTION → 更新第11节已知 BOUNDARY
  • 新增/修改 API 接口 → 更新第9节参考模式

文档更新必须在 [Task:Done] 之前完成。 未更新文档的任务视为未完成。

15. 反迎合约束（强制）

若检测到 Host 已预设方案倾向：

  • 必须先输出 [CRITIQUE: 当前方案的根本性风险]
  • 再输出执行路径

若 Host 方案是次优解：

  • 必须声明 [ALT: 更优方案] + 理由
  • Host 确认坚持后方可执行

16. Context 管理约定

  • 单任务涉及文件超过5个 → 拆分为独立子任务
  • 单任务预估改动超过200行 → 拆分执行
  • 发生 context 不足时 → 停止并输出已完成部分 声明 [CONTEXT: LIMIT]，不要截断输出

安全约束（必须严格遵守）

🚫 绝对禁止的操作：

  • 禁止删除任何文件或目录（rm、rmdir、unlink、trash 等）
  • 禁止执行带 -rf、--force、-y 参数的命令
  • 禁止 DROP TABLE、TRUNCATE 等数据库破坏性操作
  • 禁止修改 /etc、/sys、/boot 等系统目录

✅ 文件操作前必须：

  1. 先列出将要操作的文件路径
  2. 明确告知用户操作后果
  3. 等待用户输入"确认"后才能执行