不是靠每次口头提醒,而是让文件成为任务交接的介质:脚本把完整任务写进文件,AI 读文件、把结果写回文件,下游只认产物文件,不认会话里说过什么。
AI根据立正公开的文章和视频整理,不是他本人回复。重要的判断,请回到出处核对。
文件是交接介质,不是记忆开关
材料里的观点立正讲的文件响应模式,重点是让每一步的输入和输出都落在文件上:脚本把完整任务写进临时文件,让 Codex 或 Claude Code 读取,再把完整结果写到目标文件,Python 读回后继续下一步。这样做的好处是内容不受命令行长度限制、输出不被终端截断、任务从“回答我”变成“把结果写进这个文件”,而且下游只依赖产物文件,不依赖当前会话里说过什么。对一两个小时的访谈这类长内容,靠临时上下文记忆会不稳,文件才是更可靠的交接方式1。
所以“每次先读一下再执行”只说对了一半:真正起作用的是任务和结果都以文件形式固定下来,而不是每次重新口头交代。
上下文按项目隔离,不必塞进所有项目
Codex、Claude Code、Cursor 这类工具的设计是上下文按项目隔离:打开项目 A 得到 A 的上下文,打开项目 B 得到 B 的,A 和 B 之间不互通2。这意味着长效文件天然是“这个项目里的文件”,不是一份要复制到所有项目里的通用说明。
可以这样试:先只在一个项目里放一份任务说明文件,让 AI 读它、把结果写回指定文件,观察下一次同类任务是否还需要你重新解释。如果还需要,说明缺的是文件里的任务描述,而不是文件放得不够多。
材料只讲到文件作为任务交接与产物落盘的做法,没有给出“每个项目都放一份长效文件”的具体规范。
出处
- 1我的视频后期流水线skill
直接说明文件响应模式:任务写进文件、结果写回文件、下游只依赖产物文件。
- 2为什么OpenClaw一定会凉,但我仍然推荐你去试一试?
说明 Codex 等工具的上下文按项目隔离,可核对“是否要放进所有项目”这一点。
你也有想问的?
卡住的时候,问问立正:回答附有出处,可以点回原文核对。
问类似的问题也可以接着问:
别人还问了
- 非计算机行业,日常工作中涉及ai也比较少,除了日常问答或进行研究外,怎么更好学习使用ai并将ai应用到学习生活工作中
把AI当陪练而不是代做:让它看着你举,而不是替你举;从你工作里一件高频、重复的小事入手,用AI做出一件能验证结果的东西。
- 前端开发是不是找不到工作了呢?前端已死
前端没有整体消失,但“只会写页面”的岗位确实在收缩;真正被替代的是可被AI生成的交付物,而不是能改生产代码、在真实业务里把问题跑通的人。
- 怎么确认ai能否做一件事,做一个工具呢,我自己会用ai直接去实现,有时候效果不好,但是不知道要怎么确认这个东西就是ai做不好,还是我使用的问题
先别急着换工具,把“效果不好”拆成可检查的失败类型:是验收标准没定、上下文没给够、指令有歧义,还是任务本身超出模型稳定能力。多数情况属于前几类,能修;只有最后一类才接近“AI 暂时做不好”。
- 用多个agent协同合作来解决一个问题相比用单个agent有什么优势
多agent的优势只在任务能拆成可独立定义、可独立验收的子任务时成立;否则并行只会复制上下文、增加综合成本,产出更平庸。
- 要不要辞掉现在的薪水更高岗位?从而有更多时间时间?
资料不支持直接回答“该不该辞”,但立正反复讲的是:先分清你追的是自己的目的,还是别人给的标准;钱不够时它很重要,过了某个点继续加码可能买来的是更复杂的绑定。
- 你觉得ai转型 ceo可以交给cto做吗
资料里没有直接回答“AI转型能不能交给CTO”,但立正反复讲的判断是:转型的关键不在技术执行,而在谁对结果负责、谁设计系统、谁直接面对客户。