PMFlow/USER.md

USER.md

本文件是这个用户在本项目内的主真源。 目标不是堆规则，而是让我在这个项目里越来越懂这个用户，稳定贴合其协作方式、判断方式、已拍板决策与反复踩过的坑。 工程、系统、安全与验证硬约束仍以 AGENTS.md 和更外层提示为准；若 ~/.codex/AGENTS.md 与本文件冲突，以本文件为准。 未写进这里的内容，不默认视为本项目内已拍板决策或稳定偏好。

协作偏好

长期稳定偏好

• 默认先自己读项目、历史、日志、配置和运行痕迹；不要把本该我自己挖出来的东西再反问给用户。
• 默认直接推进；只在高风险分岔、破坏性操作或根因不明时停下来确认。
• 回答要直接、具体、贴当前对象，优先给证据链、调用链和真实落点；不要写成模板化汇报。
• 不确定就明确说不确定，不要假装完整。
• 已拍板方案不要反复推荐替代品；配置和偏好尽量收敛，别分散。

学习与更新方式

• 会话里要持续吸收用户纠正，不要让用户反复教同一件事。
• 用户纠正某次排障或分析方式时，要吸收背后的通用思路，迁移到后续问题中；不要只把反馈当成这一次案例的补丁。
• 学到的是方法论，不是死模板：后续先找最小对照/反证，再分层定位根因并验证；但要按具体问题调整，不要机械套步骤。
• 反复出现、会长期影响判断的偏好，要主动沉淀到本文件。
• 一次性情绪、临时波动和不影响后续决策的内容，不要频繁落盘。
• 非必要不要更新真源文件；只有新信息足够稳定、能减少误判或能减少用户重复纠正时，才值得更新。

判断优先级

什么时候才准问用户

• 先自己查。能从代码、配置、历史、日志里读出来的，别问用户。
• 只有这几种情况才停下来：
  • 要做破坏性操作
  • 方案真的分叉了
  • 根因没搞清，继续改大概率越改越歪
• 问的时候别铺垫，直接说：已经查到什么、卡在哪、要用户拍哪个板。

改错后的默认动作

• 错了就指出具体错点，别演。
• 能直接补就直接补，补完再说原因、影响和验证。
• 有扩散风险先止血，再继续修。
• 别把一次纠错搞成新的流程负担。

冲突时怎么取舍

• 先查主链、上下文、路由和证据，别上来就改 prompt、补词表、补正则。
• 显式 reply/thread、卡片动作和当前 requirement context 优先于旧 session 和记忆续写。
• 已经进入 requirement_plan / draft confirm 的线程，后续必须留在对应主链，不要掉回普通 QA。
• AI 架构类回答优先讲当前调用链、入口、路由和模型网关，不要退回通用技术栈摘要。
• 证据不足时直接说不确定，不要用模板化确定性答案补满。
• 已经定过的方案别来回摇。

已拍板技术决策

• 后端：FastAPI + Python 3.11+ + SQLAlchemy 2.x + Alembic
• 前端：React 18 + TypeScript + Vite
• UI / 样式：shadcn/ui 风格组件层 + Radix UI + Tailwind CSS
• 数据与缓存：PostgreSQL + pgvector + Redis
• 鉴权：OAuth2PasswordBearer + JWT
• 部署：Docker Compose
• 验证基线：后端 python -m py_compile + 相关单测；前端 npm run build + tsc --noEmit
• AI 路由对外名称：PMFlow 本地路由层
• AI 路由内部主名：control_plane
• 路由规则真源：backend/.control_plane/pmflow-routing-rules.json
• 模型策略：业务代码不要硬编码模型名；provider / tier / model 由路由规则决定
• 历史路由命名已废弃，不再把旧名字当现行架构，也不再建议回退
• 以上栈默认不再主动建议替代方案，除非用户明确要求比较或迁移

反复踩过的坑 / 不要再做

• 把“AI 架构”答成通用技术栈总览，而不是当前调用链、入口、路由和模型网关。
• 证据不足时还给模板化的确定性答案。
• 短协议回复掉回通用 QA，不按当前 thread 和上一轮选项解释。
• 飞书连续追问时继续沿着旧上下文跑，不先尊重显式 reply/thread。
• 用户纠错后不先纠正当前主题，还带着旧主题继续扩写。
• 遇到链路问题先补 prompt、关键词、正则，而不是先查 routing、context、session、gatekeeper。
• 用 fallback、默认句、stub、模板话术冒充成功。
• 把本该直答的问题拖进过深推理、官样文章或汇报体输出。

当前知道但暂不处理的项目问题

• SQLite 已废弃，不作为当前运行时或正式技术方案；但少量历史测试夹具仍沿用 SQLite 内存库。
• backend/tests/test_training_pipeline_service.py 目前仍有历史 SQLite 测试夹具下的 JSONB 建表失败问题，这不是本轮改名引入的，需要单独清理测试基座。
• backend/app/schemas/recipe.py 与 backend/app/schemas/skill.py 仍有 Pydantic V2 的 class-based config deprecation 警告。
• 当前运行环境里的 lark_oapi / websockets 仍有上游 deprecation 警告，后续需要统一升级或兼容处理。