观澈辨机

最近，我在使用 Codex 辅助开发时，做了一件看似普通的事情。 我将自己平时最常使用的一些开发约束、设计习惯和工程规范，整理成了一套 Skill，让 Codex 在执行任务时自动遵守这些规则。 原本只是一次简单的整理工作。 但整理到一半时，我突然意识到： 也许未来软件工程中最重要的生产活动，已经不再是编写代码，而是提炼规则。 工业时代生产的是产品。 软件时代生产的是代码。 那么 AI 时代生产什么？ 工业时代生产的是产品，软件时代生产的是代码过去几十年里，软件工程始终围绕着“代码”展开。 需求分析、架构设计、开发测试、持续集成…… 所有环节最终都会汇聚到一个核心产物： 代码。 因此，一个优秀工程师最重要的能力往往是： 如何写出更好的代码。 但 AI Agent 的出现，正在悄悄改变这一点。 今天，当我把一个需求交给 Codex 时，我已经很少亲自编写代码了。 更多时候，我在做的是： 定义规范； 补充上下文； 设计约束条件； 验证输出结果； 修正偏离方向的行为。 代码本身，反而成为了最后的产物。 这让我想到一个有趣的问题： 如果代码可以由 Agent 自动生成，...

1. 目标本 SOP 用于规范团队如何使用 Codex、OpenSpec 和 Superpowers 进行需求调研、产品规划、开发实现、测试验证、运营分析、问题排查和知识沉淀。 本 SOP 不只适用于开发工程师，也适用于产品经理、测试工程师、设计师、运营、实施交付、数据分析和其他需要沉淀项目上下文的业务团队。 核心目标： 降低新同事使用 Codex 的门槛。 避免项目上下文只存在于聊天记录中。 避免 Codex thread 上下文丢失后需要人工重新复述。 使用 OpenSpec 结构化记录需求、决策、任务进度、验证结果和业务结论。 使用 Superpowers 封装高频复杂操作，提高团队协作效率。 让团队经验可以被复用、交接和持续改进。 快速开始：新人 5 分钟版如果你是第一次在项目中使用 Codex，可以先按下面的最小流程执行： 先让 Codex 检查 OpenSpec 中是否已有相关上下文。 判断本次任务是否需要创建或更新 OpenSpec change。 小任务直接做，大任务先写 proposal、design 和 tasks。 执行过程中按 tasks 推进，不...

我见过很多团队崩掉，不是因为业务难，也不是因为人不努力，而是因为一种长期的、低强度的“窒息感”。 这种窒息感很难被 KPI 衡量，却会把团队一点点磨空：大家越来越沉默，越来越保守，越来越“只求别出错”。直到某一天，一个核心成员离职，管理者才发现：原来真正的成本，早就在看不见的地方累积了很久。 而我对这种“团队氛围的结构性来源”最清晰的一次理解，来自一个看似鸡毛蒜皮的小事：外卖。 1）外卖早到10分钟：为什么能看出一个人的管理底色？同事多次点外卖时预选了送达时段（比如 11:45–12:00），但骑手 11:35 提前送到，于是他与骑手发生争执，质问对方为什么不按时段送达。 第一次看到这种反应，我其实能理解：他可能比较较真、规则感强，希望事情按约定运行。 但当同样的争执反复发生，我开始意识到：这不是“外卖问题”，而是一个人的噪声容忍度和控制方式在外显。 外卖骑手在现实里往往是算法调度系统下的执行端：路线、顺序、时效压力、罚款机制，大部分都不是骑手个人能决定的。对执行端争执，本质上是一种“控制欲找错了对象”： 你要的是“契约严格履行” 现实是“系统动态最优化” 你把“结构问题”当...

最近一段时间，AI Agent 被描述为“可以接管一切”的存在。 写代码、跑项目、自动执行复杂流程，甚至有人认为它已经可以替代工程师。 但在实际使用之后，我的感受恰恰相反： Agent 很强，但它的边界，同样非常清晰。 一、上下文窗口 ≠ 记忆很多人会提到： “现在模型已经支持 200k 上下文，甚至更高” 但这其实是一个误解。 上下文窗口，只是当前推理时可见的信息范围，而不是“记忆”。 当信息超出当前窗口： 要么被丢弃 要么被压缩 要么被检索拼接 无论哪种方式，本质都是： 重建，而不是持有。 二、中断，不是修正，而是重构在使用 Agent 时，我发现一个非常关键的问题： 👉 它无法被中途稳定纠正。 当你发现它执行方向有偏差时，你只能： 让它继续执行 或者中断，然后补充信息 但问题在于： 中断之后，它会重新理解整个上下文。 这意味着： 新信息加入 语义权重重新分布 原本正确的部分，也可能被重新解释 最终结果是： 你不是在修正一个系统，而是在“重建一个系统”。 三、流程越长，漂移越严重Agent 在短任务中表现很好，但在长流程中会出现一个明显...

最近有一种很流行的说法： AI 会取代程序员。 听起来很合理。 毕竟现在的AI，已经可以写代码、改bug，甚至能搭出一个完整的小系统。 但我一直有一个相反的直觉： 如果有一天，真的没有人类程序员再写代码了，AI 写出来的代码，反而会越来越差。 不会更好，只会更乱。 就像一座本来就不太稳的建筑，开始在自己的残骸上继续往上加层。 一、AI写代码，更像是在“模仿”，而不是“创造”很多人把AI想得太“聪明”了。 但它做的事情，其实很朴素： 看过很多代码 → 记住大致的样子 → 拼出一段“像样的代码” 它不像工程师那样： 理解为什么这样设计 知道哪里是关键 明白什么地方不能动 它更像一个： 见过很多答案，但不一定真正理解问题的人。 所以你会发现： 它可以写得很快 也可以写得“看起来不错” 但一旦复杂一点，就容易开始漂 二、真正的问题，不在今天，而在“以后”现在的AI之所以好用，是因为它在学习： 人类过去几十年写下来的代码 但如果未来某一天： 人类不怎么写代码了，大部分代码都由AI生成。 那接下来会发生一件很微妙的事情： AI开始学习“AI自己写的代码”。 ...

不存在的一天你不会突然消失，只是系统在一层层关上识别你的门。 早高峰的地铁站，我像往常一样刷脸进地铁闸机。 地铁闸机屏幕却弹出四个字，冷静得像一纸宣判：“识别失败。” 我下意识以为是光线问题，换了个角度，再试一次。 屏幕毫无犹豫地再次拒绝：“识别失败，请改用二维码。” 我掏出手机，手机里的“市民码”不知何时已自动退出，再次尝试登录时，只跳出一句：“网络异常，请稍后重试。” 地铁站广播一如既往地循环播放市政通知，提醒市民配合“第八轮社会秩序优化数据回调计划”。 我站在人群中，暂时没觉得这事跟我有什么关系。 想赶时间，我切换了三个叫车平台，却都提示：“当前区域暂无可用车辆。” 我走到路边拦出租，一个司机看了我一眼，迟疑片刻：“兄弟，你好像没绑定市政码，我不敢拉。” 我笑了笑说：“没事，我走着去。” 办公楼的前台保安看了我一眼，没有任何反应，像第一次见我。门禁刷卡失败，我只好拨打内线电话。 助理接起电话，语气僵硬：“你今天不用过来了。” “为什么？” 她沉默两秒，像在权衡什么，然后低声说：“我也不知道。但我建议你，不要在门口站太久。” 我转身，看向办公楼的玻璃幕墙。 我的倒影立在那里，...

引言：一个看似技术的问题很多软件项目在立项之初，都有一个美好的开端。 模块化、抽象、解耦、可复用组件，这些词反复被提起。架构图干净而优雅，边界清晰，职责分明。每一个模块看起来都站在自己“合理的位置”上。 但项目一旦进入中后期，现实往往迅速坍缩。 模块开始膨胀，依赖开始交错； 改一处逻辑，却在远处引发连锁反应； 所有代码都“有理由存在”，但系统整体却越来越难以理解、难以维护。 这时我们通常会把问题归结为： 代码写得不够好，抽象不够到位，或者“当初设计不够周全”。 但从结构主义的视角来看，也许真正的问题并不在代码质量本身，而在一个更隐蔽的地方： 控制权，被放在了错误的位置。 一、从结构主义看“依赖”的本质在结构主义的语境中，个体从来不是核心，关系才是。 一个模块“依赖”另一个模块，表面上是技术关系； 但在结构层面，它同时意味着一种决定权的归属。 谁创建谁 谁选择谁 谁可以被替换，谁不可动 当一个高层模块在内部 new 出具体实现时，它不仅在使用对方，还在决定对方的存在方式。 从这个角度看，“依赖”并不是中性的。 依赖，本质上是一种权力关系。 谁掌握创建权，谁就掌握了对系统演化方...

前言：我们其实一直在使用“无名的思想”很多软件工程师认为自己是实践主义者，靠经验、逻辑和动手能力解决问题。我们习惯在需求、代码、架构和调试中穿梭，而对“哲学”“思维模型”这些看似玄学的词保持距离。 但如果你把目光从工具移向结构，从术层走向思维本质，你会发现： 我们早已在不自知中，使用着一套套经典的思维模型，只是它们换了名字，藏在了工程实践里。 在软件工程中，这些模型没有被刻意提及，也没有出现在文档中，但它们是我们解决复杂问题的隐性支撑。 本篇文章将带你从软件工程中常见的实践出发，追溯它们背后的“思维原型”。你会惊讶地发现：你已经是一个哲学的践行者了，只是你用的是代码语言。 一、MECE 原则：模块化设计与职责边界MECE（Mutually Exclusive, Collectively Exhaustive）是咨询行业的分析圣经，但在软件工程中，它以另一种语言活跃着： 函数单一职责原则（SRP） 模块高内聚、低耦合 微服务架构中的“限界上下文” 这些原则的目标，正是实现“职责互斥”（或理解为模块独立）与“穷尽覆盖”——每个模块只做一件事，所有模块加起来正好覆盖系统全貌。 M...

一场关于认知结构的隐秘分配 “哲学并不复杂，复杂的是你是否拥有思考它的结构位置。” 一、哲学并非天然高冷，而是在人群中被悄然分层很多人觉得哲学遥不可及，是讲堂上的抽象学问，是政策制定者的视角，是那些“有闲阶层”的精神消遣。 它似乎距离普通人的生活很远，甚至显得“无用”。 但这不是因为哲学本身难懂，而是因为——理解它、使用它、实践它所需的结构性资源，并未被公平分配。 哲学从来不是只为少数人准备的答案，它更像是一种可被训练的思维方式，一种在混乱中找方向的能力。 二、哲学为何总是离普通人更远？1. 它不解决“眼前的问题”哲学不会直接告诉你这份方案怎么写、这个老板如何应对、房贷压力如何缓解。 它关注的是：你为什么做这份工作？你面对选择时依据的价值是什么？ 当生活节奏被压缩为“做完下一件事”，很多人甚至没有意识到自己已经很久没问过“为什么”了。 2. 它需要“无用时间”哲学不是为了结果展开的，它更像一种停顿中的练习。 但现实中，停下来本身就是一种奢侈。 当你没有多余空间时，连思考都变得沉重。 3. 它从未被当作一种“可习得的能力”我们被教导要解题、要记住结论，却很少被训练如何提出好...

“真正有价值的批评，不是直率的发泄，而是结构的照见。它既要冒着得罪你的风险，又要承担对结构负责的代价。” 一、你真的想听“批评”吗？你有没有过这样的体验： 当你好心提醒一个朋友的问题，他非但不感激，反而翻脸；当你忍不住指出团队决策的偏差，众人却觉得你太“负面”；你本以为是在帮助他们看见盲点，但最终换来的是抵触、冷眼，甚至孤立。 这不是个例，而是一种结构性现象。 批评从来就不该是免费的。 真正有价值的批评，是一种稀缺的认知服务。它耗费的不只是时间，还有洞察力、结构建模力、表达能力、以及与被批评者之间的微妙张力调控。 如果你没有为此付出任何代价，你凭什么认为对方会为你认真动脑，反过来还要小心翼翼地照顾你的玻璃心？ 二、批评是一种高成本的认知劳动在信息爆炸的今天，我们以为“观点”唾手可得，殊不知真正能改变一个人命运的，不是信息，而是结构化的认知反馈。而这，正是批评最稀缺的价值所在。 一个真正有力量的批评，往往需要下面这些结构性能力： 结构洞察力：能看出你问题的真正根源； 语言组织力：说得你听得进去，而非让你自动防御； 情绪拿捏力：既不冷漠，也不讨好，还要避免对抗； 认知建模力...