一、开始任务前写清楚结果
存在的问题
我经常先说“帮我看看这个项目”或“优化一下文档”，执行过程中再补充范围、读者、限制和验收要求。这样容易返工，也会让对话越来越长。
改进例子
开始任务时直接写清楚目标、来源、约束、交付和验收：
目标：把当前项目的 readme 改成初学者可以独立执行的使用指南。
来源：以当前工作区的代码和脚本为准，不要根据旧对话猜测。
约束：只修改 readme，不修改代码，不包含本机路径和内部地址。
交付：直接修改文件，并总结主要变化。
验收：命令必须与项目一致，markdown 格式正确。二、一次说清允许执行到哪一步
存在的问题
我习惯在调研、修改、检查、提交和推送的每一步都 review。高风险操作需要确认，但普通的读取、编辑和本地验证也反复暂停，会降低整个任务的效率。
改进例子
在开始时一次说明允许执行的范围和必须暂停的情况：
允许你读取当前项目、修改指定文件并完成本地验证。
验证通过后直接提交并推送，只提交本次修改。
如果需要修改其他模块、删除内容或改变环境，先停下来说明原因。如果只需要方案，也直接说明：
本次只分析和提出方案，不修改文件。输出问题、建议和下一步操作，等我 review。三、重复工作不要每次重新对话
存在的问题
相似任务仍然经常从临时对话开始，需要重复说明输入、步骤、安全边界和输出格式。不同类型的任务也容易放在同一个长对话中，增加无关上下文。
改进例子
先根据任务类型选择合适的方式：
讨论问题、比较方案 → chat
生成文档、表格或演示文稿 → work
修改仓库、运行测试和检查代码 → codex
重复执行且步骤固定 → skill
需要定时运行 → automation例如每周工作总结，第一次手动执行并确认结果，第二次补充异常处理，第三次流程稳定后保存为 skill；如果还需要每周自动执行，再创建 automation。