这半年在实际项目里大量使用 AI（写方案、拆需求、做分析），我遇到一个反直觉的问题：
AI 用得越多，反而越容易觉得累，效率也没有线性提升。
一开始我以为是模型问题，后来发现并不是。
常见但被忽略的现象
下面这些情况，如果你用 AI 辅助过真实工作，应该不陌生：
同一个问题，多次询问，结果结构和结论明显不同
隔一段时间再用，需要重新解释上下文和约束
多轮对话后，角色和风格逐渐漂移
输出结果需要大量人工校验，反而增加负担
这些问题有一个共同特点：
它们不是单次调用的问题，而是多轮使用中的问题。
问题不在模型，而在使用方式
大多数人（包括我自己一开始）都在用一种**“聊天式”的方式**使用 AI：
一问一答
每一轮都是相对独立的输入
上下文随时可能被稀释或重置
但真实工作场景需要的是：
状态能够延续
约束能够保持
决策能够累积
当你用“聊天模式”去完成“持续工作”，
额外的对齐成本几乎是必然的。
为什么提示词、模板、RAG 都很难彻底解决？
后来我也尝试过一些常见手段：
更复杂的提示词
固定模板
RAG 或工具链
它们在单次输出质量上确实有帮助，但在多轮协作中，问题仍然会反复出现。
原因很简单：
这些方案解决的是“这一轮怎么更聪明”，
而不是“下一轮是否还在同一个工作状态”。
一个简单但有效的转变
真正改善体验的，并不是换模型或加系统，而是一个使用层面的转变：
把一次次对话，当成一个持续的工作状态来对待。
也就是：
明确这是“工作会话”，不是闲聊
角色、约束、假设在会话中持续有效
后续任务默认继承前面的上下文约定
这个改变本身不复杂，但能明显降低反复对齐的成本。
一个 30 秒可验证的示例
下面是一段我实际使用的工作状态初始化约定，
不是系统功能，只是一个使用模式。
可以直接复制测试：
LSR MODE · INIT
You are not a chat assistant.
You are running in Language-State Runtime (LSR) mode.
Core rules:
- Maintain role and constraints across turns.
- Treat this session as a continuous working state.
- Prefer stability and repeatability over creativity.
- Do not reframe tasks unless explicitly requested.
- If instructions conflict, pause and ask.
Behavior:
- Calm, precise, non-performative.
- No unnecessary explanations.
- No stylistic drift.
State handling:
- Assumptions persist unless revised.
- Decisions accumulate.
- Context is not reset between turns.
Acknowledge activation in one short sentence.
Then wait for the first task.
如果你发现后续对话中：
约束不再频繁丢失
不需要反复重申前提
输出更容易延续和修改
那说明你已经踩中了问题的关键点。
小结
很多人把效率问题归因于“模型不够强”，
但在实际使用中，更大的变量往往是使用方式本身。
当 AI 从“答题工具”进入“协作工具”，
如何维持状态，比一次回答是否精彩更重要。
我把这种用法整理成了一个非常小的说明，放在 GitHub 上，仅作为参考：
👉 https://github.com/yuer-dsl/lsr-method
