把环境事实写进 Rule
模型配置、技术栈锁定、数据格式三分法与 isComposing 这类必踩的坑
本页解决的问题
先给结论「把环境事实写进 Rule」要解决的关键问题是什么？
模型配置、技术栈锁定、数据格式三分法与 isComposing 这类必踩的坑
把品味变成产品可重复的行为。 有用的结果不是一句“我觉得更好”。它应该是一条看得见的规则、一个小例子，以及判断体验何时低于标准的方法。
记录一个前后对比，让别人不用听解释也能看懂质量线。
表面更精致了，却没有减少用户的不确定感。
为什么是 Rule：把配置写在 .env 里让 AI 自己读，它不一定每次都主动读；写在对话里，对话一长就被截断遗忘。Rule 在每轮对话开始前就被加载进上下文，是最稳的注入方式。
中文输入法确认候选词时会触发 Enter，只判断 e.key === 'Enter' 的输入框会把半段内容直接发出去。AI 训练数据里 isComposing 覆盖率不高，不写进 Rule 就一定会忘。切换到中文输入法，在下面的输入框里打几个字试试。
const handleKeyDown = (e: React.KeyboardEvent) => {
if (e.key === 'Enter' && !e.shiftKey
&& !e.nativeEvent.isComposing) {
e.preventDefault()
handleSend()
}
}isComposing为true：输入法正在组合中，回车只确认候选词，不触发发送isComposing为false：普通键盘直接输入，回车正常发送- 规则原文：禁止只判断
e.key === 'Enter'而不检查isComposing
数据格式三分法：三种格式各管一个领域，互不混用。点击场景，再选一个你认为合适的格式。
{
"tool": "send_message",
"arguments": "{\"channel\": \"dev\",
\"payload\": \"{\\\"title\\\":
\\\"发布提醒\\\", \\\"body\\\":
\\\"v1.4 已上线\\\"}\"}"
}<tool_call name="send_message">
<channel>dev</channel>
<payload>
<title>发布提醒</title>
<body>v1.4 已上线</body>
</payload>
</tool_call>JSON 版每层嵌套翻一倍反斜杠，LLM 逐 token 生成时极易配错括号和引号。XML 标签闭合直观，模型出错率更低。
进度：0 / 3 个场景
图像生成至少 120-180 秒
图像 API 经常因为默认 30 秒超时失败，AI 还会反复尝试相同的错误配置。HTTP 客户端的超时值写进 Rule，一次解决。
网络失败先挂代理重试
网络请求失败时必须尝试代理重试（默认 127.0.0.1:7890），仍失败才向用户报告，禁止跳过代理直接报错。
前端可见响应必须流式
前端可见的所有大模型响应必须用 Streaming 返回，后端内部调用才允许非流式。
选型是人的决策
- 后端 FastAPI、前端 React + Tailwind + Vite、数据库 SQLite、向量库 Chroma
- 一旦定了就不再讨论替代方案，AI 的职责是在确定的栈内把代码写好
- 端口避开 5000，从 8000-9000 随机分配，多项目同开也不冲突
图标与细节规范
- 禁止用 emoji 做按钮图标，图标必须用 SVG
- 看产品调性选图标集：SaaS 用 Lucide，温暖调性用 Tabler Icons
- 图标直接下载到本地使用，不依赖 CDN
补充说明：只用 GPT 系列的项目可以把工具调用改回 JSON，它的 function calling 原生就是 JSON。「Agent 用 XML」是多模型混用场景的最大公约数选择，Claude 系模型在 XML 格式上表现更稳定。
提交物：Rule 的环境配置章节。① 列出你项目的环境事实：模型、API 服务商、超时、代理、技术栈、数据库；② 写成 Rule 章节，敏感的 Key 放独立的 secrets 文件并加入 .gitignore；③ 新开一个对话验证：不做任何交代，AI 能否直接说出你的技术栈和模型配置。
素材来源：开源仓库 itshen/xs_vibe_rules 中 rule-opensource.mdc 第一章「模型配置」、第四章「文档与设计规范」、第五章「数据格式规范」、第六章「技术栈与框架」。
从「交互体验一 · isComposing，用中文输入法亲自试」把感觉变成判断
「为什么是 Rule： 把配置写在 .env 里让 AI 自己读，它不一定每次都主动读；写在对话里，对话一长就被截断遗忘。Rule 在每轮对话开始前就被加载进上下文，是最稳的注入方式」指出，AI 降低了做出“能用”成品的门槛，读者真正需要练的是看出哪里不对，并把感觉说成可以执行的要求。
观察用户的下一步，而不是只看表面
「中文输入法确认候选词时会触发 Enter，只判断 e.key === 'Enter' 的输入框会把半段内容直接发出去。AI 训练数据里 isComposing 覆盖率不高，不写进 Rule 就一定会忘。切换到中文输入法，在下面的输入框里打几个字试试」可以转成几个可观察的问题：用户是否知道现在发生了什么，是否知道下一步做什么，出错或空白时能否恢复，以及信息层级是否让重要内容先被看见。
- isComposing 为 true ：输入法正在组合中，回车只确认候选词，不触发发送
- isComposing 为 false ：普通键盘直接输入，回车正常发送
- 规则原文：禁止只判断 e.key === 'Enter' 而不检查 isComposing
漂亮不等于容易用
把「提交物：Rule 的环境配置章节。① 列出你项目的环境事实：模型、API 服务商、超时、代理、技术栈、数据库；② 写成 Rule 章节，敏感的 Key 放独立的 secrets 文件并加入 .gitignore；③ 新开一个对话验证：不做任何交代，AI 能否直接说出你的技术栈和模型配置」用在第二个页面或流程上，记录一个具体犹豫点和一个改动后的用户动作；能被观察到的变化，才是体验改善。
从「交互体验一 · isComposing，用中文输入法亲自试」走到「交互练习二 · 这个场景该用什么格式」
「交互体验一 · isComposing，用中文输入法亲自试」先把问题落在「中文输入法确认候选词时会触发 Enter，只判断 e.key === 'Enter' 的输入框会把半段内容直接发出去。AI 训练数据里 isComposing 覆盖率不高，不写进 Rule 就一定会忘。切换到中文输入法，在下面的输入框里打几个字试试」上；到了「交互练习二 · 这个场景该用什么格式」，讨论继续推进到「数据格式三分法：三种格式各管一个领域，互不混用。点击场景，再选一个你认为合适的格式」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
评估体验时，把抽象的“好看”或“顺手”换成用户动作：他是否看懂状态、找到了下一步、能从错误中恢复，并且愿意继续使用。
- 「交互体验一 · isComposing，用中文输入法亲自试」：中文输入法确认候选词时会触发 Enter，只判断 e.key === 'Enter' 的输入框会把半段内容直接发出去。AI 训练数据里 isComposing 覆盖率不高，不写进 Rule 就一定会忘。切换到中文输入法，在下面的输入框里打几个字试试
- 「交互练习二 · 这个场景该用什么格式」：数据格式三分法：三种格式各管一个领域，互不混用。点击场景，再选一个你认为合适的格式
- 「最后的要点」：一旦定了就不再讨论替代方案，AI 的职责是在确定的栈内把代码写好
最后的「最后的要点」把讨论落到「一旦定了就不再讨论替代方案，AI 的职责是在确定的栈内把代码写好」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。