计算机不只应替你算答案，也可以帮助你把问题想清楚
把任务完全想清楚后才允许使用工具，是一种合作方式；边试、边看结果、边修正问题，则可能支持另一种思考。
谁在何时、何处提出
J.C.R.利克莱德在1960年已有明确记载的〈人机共生〉（Man-Computer Symbiosis）中讨论了这一思想。定位：〈人机共生〉摘要与第二至四节。
论文发表于1960年3月《IRE Transactions on Human Factors in Electronics》，4—11页；本次核对MIT保存的全文转录，现代工具只是类比。
核心意思与容易误读之处
利克莱德设想紧密的人机合作，让计算机参与问题形成与实时思考，而非只执行预先完整写定的程序。他也区分人的目标设定、判断与机器适合承担的重复处理。
本文转述为：设计一个能反复来回的过程，而不是一次把要求扔给工具，再把输出视为结论。今天可以借此安排计算、检索和草稿工作，但不应把现代系统的能力或可靠性倒推成作者当年已经验证的事实。
例如做一个排程表时，人先决定哪些时间不可占用，工具负责发现冲突，再由人解释为什么某种安排虽无冲突却不合适。来回修正让问题本身逐渐清楚。关键不是工具产生了多少候选方案，而是每次交互是否帮助辨认约束、暴露假设并改善判断。如果只是不断要求重做，直到输出看起来顺眼，合作仍缺少可检验的依据。
为什么落实起来仍有阻力
本篇归入B类：观点已有传播，但把它落实成日常做法仍需要条件。没有找到可靠的总体采用率数据；以下是对执行阻力的分析，不是“大多数人没做到”的统计结论。
一次性交付容易分配责任，也容易演示效果。真正交互式合作需要保留中间结果、解释不确定性并允许修改，产品和使用者都要付出额外设计成本。
另一项阻力是角色模糊。人可能被动接受机器建议，也可能坚持亲自完成所有细节；两种极端都没有认真检查哪些环节需要人的判断、哪些适合可靠自动处理。
今天做一个小实验
这是据上述思想设计的个人练习，用来发现线索，不是原作者的标准实验，也不预先保证一定有效。
用45分钟处理一个低风险的规划问题，例如安排一周个人阅读。前10分钟由自己写清目标、可用时间与约束；用10分钟借助表格或现有工具生成两种安排。
再用15分钟检查冲突、遗漏和假设，修改输入后重算；最后10分钟说明最终方案为什么改变。交付一份含初始条件、工具输出与人工修正的记录，不输入隐私资料，也不让工具替你作重大承诺。
什么时候不宜照搬
工具可能错误、遗漏或不适合当前问题，交互次数增加不等于结果更可靠。人仍须核查关键条件并承担相应判断。这个观点不是要求所有工作都使用人工智能，普通表格、计算器和可编辑图示也能支持这种往返。