核心定位
把你的产品开发经验，变成 Agent 可执行的 Markdown 标准。
这些标准会放进项目目录里，成为跨 session、跨工具、跨 Agent 都能读取的共同上下文。
它是什么
一套让 Agent 开工前先对齐产品、工程和协作方式的标准。
Motux Dev 不是一个具体业务模板，也不是某个框架脚手架。它更像一份给 Codex、Claude 和其它 Agent 读取的项目工作协议，让它们知道什么时候该问、什么时候该做、怎么记录、怎么验证。
给人看
让用户知道开发前要想清楚什么，哪些决策需要自己拍板，哪些技术细节可以交给 AI。
给 Agent 执行
让 Agent 按任务类型读取相关标准，避免每次都从零解释同一套偏好和踩坑经验。
解决哪些问题
它解决的是 AI 开发里最消耗时间的重复纠错。
很多项目不是做不出来，而是每次都在同样的地方返工：需求没问清、界面不自然、上下文丢失、 多个 Agent 互相覆盖、测试和提交不稳定。
需求还没想透就开始写代码
要求 Agent 先追问产品目标、核心假设、用户故事和最小验证路径。
界面看起来能用，但不够像人用的产品
把 storyboard、视觉确认、分步交互、按钮反馈和移动端检查前置。
同一个项目里 Codex 和 Claude 信息不同步
把关键进展、决定、风险和下一步写入项目记忆，而不是只留在聊天记录里。
每次开新项目都要重新解释偏好
把你的工作方式、质量标准和安全边界沉淀成可复制文件。
运行中项目接入 AI 时容易误改
先读取现有规则，遇到冲突不覆盖，接入阶段只梳理、不乱动业务代码。
开发过程不可回溯
要求小步验证、更新交接、必要时提交 Git，让每次修改都有上下文。
适合什么用户
尤其适合用 AI 做产品开发，但不想反复教同一件事的人。
产品出身的独立开发者
你擅长判断用户、场景和价值，但不想在工程细节上被反复拖住。
同时使用 Codex / Claude 的用户
你需要不同 Agent 共享项目记忆，避免每换一个工具就丢掉上下文。
经常从 0 做原型的人
你需要新项目快速进入需求澄清、界面确认和最小可验证版本。
想把 AI 接入旧项目的人
你需要先保护已有代码和规则，再逐步把更好的协作标准合并进去。
为什么使用
让用户做自己最强的事，让 AI 补用户最弱的地方。
它的价值不是让流程变重，而是减少反复纠错。用户把产品判断、审美偏好和业务目标讲清楚， AI 则负责把这些判断转化成工程执行、验证和记录。
先把产品想清楚
明确为什么要做、核心价值是什么、谁会使用、哪些需求应该先验证。
再把界面看清楚
用 storyboard、页面清单和视觉确认减少理解偏差，避免把所有功能堆在一页。
最后小步可回溯
功能拆小、做完验证、记录决策、更新交接，让不同 Agent 接手也不丢上下文。
如何使用
理解之后，只需要复制一段提示词给 Codex 或 Claude。
先选项目状态。Agent 会完成接入文件准备，并把关键进展记录在项目里。
从 0 开始
自动下载新项目标准，并进入产品澄清。
适合一个新产品、新工具或新原型。Agent 会把入口文件、项目记忆模板和完整标准放到项目根目录。
提示词
新项目自动接入
两种场景
用户不用理解文件结构，只要选对项目状态。
新项目
把 Motux Dev 的入口文件、项目记忆模板和完整 Agent 标准放入项目根目录。
- 适合从 0 开始的产品、原型或工具。
- 接入后先做产品目标、用户故事、界面流程和技术风险澄清。
- 如果目录里已有同名文件，先放入冲突区，不直接覆盖。
已开发中的项目
轻量接入项目记忆和标准参考，让 Agent 先理解现状，再讨论是否合并入口规则。
- 适合已经有代码、已有 README、已有 AGENTS.md 或已有部署方式的项目。
- 默认不改业务代码，不重建架构，不覆盖原有 Agent 规则。
- 先输出当前状态、已知决策、风险和下一步。
安全边界
运行中项目的重点是“不覆盖、不乱改、先汇报”。
同名文件不覆盖
如果项目里已经有 AGENTS.md、CLAUDE.md、docs/project/
文件，Agent 会把 Motux 版本放进 docs/motux-incoming/，再提出合并建议。
先读现有规则
对已有项目，Agent 必须先读取 README、现有 Agent 规则、配置和入口代码，理解项目原本的约定。
不暴露敏感信息
不要把账号、密钥、服务器密码或私钥贴进聊天；需要输入密码时，优先让用户在终端中输入。
先记录再开发
接入完成后，先更新项目记忆，再进入需求、界面、工程或交付任务。