铁锤人
5个月前
Reddit 上有个火贴:有个工程师抱怨 AI 不可靠 对大部分在上班的程序员来讲,可靠性就是生命。可靠性和奖金,晋升挂钩。殊不知,这个倾向只不过是公司用工资驯化出来的结果。 我现在还保有这个倾向,我环洱海骑行的时候。有 70km 的公路上,公路车车道被拿来当停车位。 我出发的前一晚,都在纠结如何,非机动车道变机动车道时,如何不被后方来车碾过,因为公路车没后视镜。想着想着,我都不敢去环洱海了。 后来 ban 总拉着我骑到那个路段,我发现想象中的极端情节没有发生。 之前在我脑海中,大车满天飞,非机动车道上都停满汽车。 实际上,少数时间有个大车过来,自行车道没多少车。我们变道时候,先看看前方有没有障碍,然后回头看有没有汽车来过。 后来,连续这么变道太累了,我干脆就直接在机动车道侧边行驶了。有车过来的时候,它自己绕开我了。 说了这么多,我的意思是说,这个世界大部分的风险不是突变的,是缓慢增加,低概率发生的。 我们要做的是,监控,在风险扩大之前,逃过就行。 拖头车司机也不是傻逼,远远见到你肉包铁就马上减速。骑车噪声很大,你听了肯定避让。 这些风险不是突变的,是能预测的。 这个时候有人就会说了,为什么要去冒这个风险呢?平稳不好吗? 假如你想这辈子活的不一样,那你就只能离开羊群,去寻找新的草原。 毕竟羊群里面没有多少草了,而且格外拥挤。
铁锤人
5个月前
你仍然需要思考 随着编码智能体(coding agents)的能力越来越强、运行时间越来越长,这并不意味着人类“思考”的工作就被取代了。总得有人来负责指挥这些工作——设定目标、选择约束条件,并对输出结果作出判断。 大家在抽象层面上似乎都认可这一点,但几乎没有人真正讨论过一个事实:产品形态的不同,实际上会从根本上改变“写代码”时所需的思考方式。 💭 不同产品形态对“思考预算”的影响 我认为,不同编码智能体之间看似细微的 UX(用户体验)差异,实际上对用户“思考预算”的分配方式有着巨大的影响。 远程型产品(如 Codex Cloud,而非 CLI): 这种产品鼓励你不要在智能体工作时花太多精力思考,而是更多地在最后拿到结果后再思考。 我们甚至刻意不让用户看到智能体调用终端命令的过程,因为模型的工作方式和人类有本质区别。 交互式产品(如 Claude Code 或 Codex CLI): 在这种产品里,你会花更多时间去思考规范和智能体采取的高层方案,因为你可以在终端中“跟随”它的思路。 不过,你需要在其他地方(如编辑器或 GitHub)查看代码差异,因此工作流程更多是在跟进智能体的计划并验证执行过程。 IDE 集成型产品(如 Cursor): 你会快速地接受或拒绝智能体给出的代码改动。 因为上下文已经在编辑器中,所以你无需花太多心思去提供上下文信息,但这意味着你可能需要提前花时间把问题拆解好,在最开始就想清楚计划和方案。 🧠 “思考预算”的四个主要环节 所有这些产品都需要在以下四个环节之间重新分配“主动思考”的时间: 提供正确的上下文 制定计划 实现代码 验证和审查 就目前 LLM 的能力而言,我的判断是: 👉 实现(3) > 验证(4) > 规划(2) > 提供上下文(1) 也就是说,“提供上下文”仍然是人类价值最大的地方。在我们拥有更好的组织内搜索工具、用户信息提取工具、全局上下文理解能力之前,这一点都不会改变。 另一方面,LLM 在接收清晰的计划并实现它时表现非常出色。它们能很好地处理竞态条件、错误处理以及复杂的技术细节。 🔍 不同问题 & 不同思考方式 如果你接受“思考预算”这个概念,就不难理解为什么工程师在使用不同工具时的体验差异会如此巨大: 有些问题只需要一个清晰的规范——你已经完全知道实现的样子。 有些问题需要通过写代码来“思考”问题本身,然后再进行重构。 有些工程师更喜欢先看一版初稿再进行审查,而不是从零开始写。 不论你偏好哪种方式,不同的产品体验都要求你用不同的方式来思考。我认为不太可能出现一种“单一工作流程”就能满足所有用户的需求。 你依然需要思考……但最好的产品,会让用户自己选择他们想要“如何思考”。