五、概念哲学篇 (开放思辨)
Q23. 为什么应该”保持 context 简单”? 一个塞满信息的 prompt 不是更好吗?
讨论方向:
注意力是有限资源 —— LLM 的注意力机制对相关内容的权重并非均匀, 过多无关信息会稀释关键指令的权重 (“lost in the middle”现象).
token 成本 —— 每次推理都按全部 context 计费 / 计算; 长 context 直接拉高延迟和账单.
可调试性 —— 出问题时, 短 context 容易定位是哪条指令冲突; 长 context 几乎不可能复盘.
可演化性 —— context 越简单, 越容易迭代 / 替换 / 重排; 复杂 context 像一团 spaghetti.
哲学层面: “简单”不是”少信息”, 而是”高信噪比”. 让 agent 知道它需要知道的, 而不是所有可能有关的.
Q24. Agent 应该”主动”还是”被动”? 它什么时候该问用户, 什么时候该自己决定?
讨论方向:
行动的可逆性 —— 可逆的 (本地改个文件) 自决; 不可逆的 (push、delete、send email) 必问.
影响半径 —— 只影响本机 / 自决; 影响共享系统 (CI、PR、Slack) / 必问.
不确定度 —— agent 自己心里没底的时候应该问, 而不是赌一把.
用户当前可达性 —— 用户在线就多问; 后台 / 离线任务 (cron) 倾向于保守自决.
设计哲学: 真正好的 agent 不是”什么都不问”或”什么都问”, 而是问对问题 —— 关键岔路问, 鸡毛蒜皮不打扰.
Q25. “Vibe Coding” 到底是 hype 还是范式革命?
讨论方向 (鼓励多元观点):
Hype 派论点: 这只是更智能的自动补全; 复杂项目里 agent 仍然会犯低级错误; 维护成本被低估.
范式派论点: 编程的”主单位”从”行/函数”上升到”意图/约束”, 工程师角色从”打字员”变成”架构师 + 审稿人”; 软件交付速度的瓶颈正在被打破.
中间立场: 是范式革命, 但不是 1:1 替代 —— 它放大了高水平工程师的能力 (因为他们能给出好 spec 和好 review), 也放大了低水平工程师的破坏力 (因为他们也能快速产出垃圾).
关键追问:
如果 agent 写代码, 知识在哪里沉淀? 是仓库 (CLAUDE.md) 还是个体大脑?
“代码 review” 的角色会不会比”写代码”更重要?
教育、入门门槛、初级岗位会如何变化?
Q26. 一个 agent 反复改不对一个 bug, 你应该让它继续试, 还是关掉自己上?
讨论方向:
信号识别: Agent 已经在”循环尝试同一类错误解” → 上下文已被污染, 继续多半无效.
沉没成本: 已经烧了多少 token 不重要, 重要的是”再烧 X token 能否解决”, 概率 / 成本不划算就停.
元问题: Agent 卡住通常意味着信息缺失而非推理失败 —— 此时应人工补信息 (贴日志、贴文档、贴失败用例), 而不是让它继续猜.
健康习惯: 给自己定一个上限 (例如”agent 改 3 次还不对就接手”), 避免无意识的 over-reliance.
哲学: Agent 是放大器, 不是替代品. 当它放大的是死胡同时, 越用越深.
Q27. 为什么”测试驱动开发 (TDD)” 在 agentic 工作流里比传统工作流更重要?
讨论方向:
Agent 容易”自信地写错” —— 它会编 API、编字段、编返回值, 测试是唯一的客观裁判.
测试是和 agent 沟通的契约 —— 你不需要详细描述”怎么做”, 你只需要说”做完后这个测试必须过”.
TDD 给 agent 提供了反馈循环** —— 没有失败的测试, agent 不知道自己错没错.
TDD 强制把模糊需求变成可执行规约 —— 这恰好是 agent 最需要的输入.
风险: 反向地, 如果 agent 自己写测试又自己写实现, 它可能”为了过测试而过测试”. 关键测试 (验收级、安全级) 应由人写或独立 review.
Q28. “agent 写的代码可读性差” 该怎么办? 这是工具问题还是用法问题?
讨论方向:
工具侧: 模型确实有”过度抽象 / 过度防御 / 过度注释”的倾向; 系统 prompt 里限定 (例如 Claude Code 默认 prompt 就有”不要加无意义注释”) 能改善.
用法侧: 用户没给约束 / 没 review / 接受 first try → 垃圾代码堆积. 这是用法问题, 不是工具问题.
根本解:
在 CLAUDE.md 里写明可读性硬规则 (函数长度、命名、注释规约).
把”简化 / 重构 / 删冗余” 作为独立 step, 而不是寄希望于 first try.
把 review 标准外置成 skill (如 simplify、code-reviewer), 强制 agent 自审.
更深一层: agent 写的代码”读不懂”, 还是因为读的人没有花时间理解. 如果完全不读, 那相当于把生产代码外包给了一个不会被追责的实习生.
Q29. “我让 agent 跑了一整晚, 它做了什么我看不懂” —— 这是 agent 该解决的问题还是用户的问题?
讨论方向:
可观测性是工具方的责任 —— agent 必须能输出可审计的操作序列 (file diff、command log、决策点).
理解力是用户方的责任 —— 工具再好, 跨夜 1000 次 tool call 也不可能逐条审; 必须事前约定边界 (例如 permission mode = plan, 或者只让它跑特定子任务).
设计哲学: 越长的自主任务, 越需要强约束 + 阶段 checkpoint, 而不是”放手让它跑然后审”.
极端情形: 完全无人监督的长跑 agent, 风险类似于”无人监督的初级实习生 + sudo”, 在生产环境基本不能接受.
Q30. 终极思考题: agentic 工具最终会让”程序员”这个职业消失吗?
讨论方向 (没有正确答案):
不会消失, 会重塑**:** 写代码的部分被外包, 但理解需求 / 拆分系统 / 判断对错 / 承担责任这部分永远需要人.
会消失一种”程序员”: 那种把工作完全定义为”打字实现 spec”的中下层岗位, 风险显著.
新角色会出现:
“Agent 架构师” —— 设计 agent 协作图、skill 库、context 策略.
“AI 审稿员” —— 能高速 review agent 输出的资深工程师.
“Context 工程师” —— 把领域知识结构化为 agent 可消化的形式.
历史类比: 编译器没有让汇编程序员消失, 但确实让”手写 x86”的人变少了 —— 程序员的抽象层次会再上一层, 而不是被取代.
个人立场题: 你认为 5 年后, 你日常工作的什么比例还是”自己打字”? 30%? 5%?