87 lines
5.1 KiB
Markdown
87 lines
5.1 KiB
Markdown
# 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 警告，后续需要统一升级或兼容处理。
|