观澈辨机

一次软件研发组织范式的重新思考。 一、为什么今天讨论的是组织，而不是 AI？过去两年，AI 在软件研发中的讨论大多围绕工具展开： AI 是否能写代码？ AI 是否能提高开发效率？ AI 是否会替代程序员？ 这些问题都很重要。 但经过持续实践，我们越来越认为： AI 带来的最大变化，不是开发方式，而是组织方式。 真正值得讨论的，不是某个 AI 工具，而是： 软件研发组织将如何演进。 二、软件研发组织的三次演进第一阶段：个人开发（Personal Development）软件规模较小时，一个人可以完成产品、开发、测试和部署，组织成本最低。 但随着系统越来越复杂，个人能力逐渐成为瓶颈。 第二阶段：多人组织（Multi-person Organization）这是过去几十年软件工程建立起来的组织范式：通过专业化分工解决复杂性。 典型组织链路是： 1产品 → 设计 → 前端 → 后端 → 测试 → 运维 软件工程中的大量理论和实践，包括： 项目管理 敏捷开发 DevOps 微服务 CI/CD 软件质量体系 本质上都在回答同一个问题： 如何组织更多的人，共同...

最近在使用 Codex 推进开发时，我越来越强烈地感受到一件事： AI 改变了软件开发的生产方式，但它并没有让过去几十年形成的软件工程思想失效。 恰恰相反。 当 Agent 能够越来越快地理解需求、修改代码、运行测试，甚至独立推进一个复杂任务以后，过去很多为了“提升开发效率、控制复杂度”而形成的软件工程方法，开始表现出新的价值。 最直观的感受是： 更省 Token，也更不容易跑偏。 但如果继续往下看，会发现 Token 只是表象。 真正发生变化的是： 软件工程正在从“管理人的复杂度”，进一步变成“管理 Agent 的不确定性”。 而 Agent 越强，这件事情反而越重要。 从我以前做过的 ProTable 说起很多年前，我做前端架构时，开发过类似 ProTable 这样的基础组件。 当时的目的很简单。 业务系统里有大量列表页面：用户列表、订单列表、客户列表、审批列表…… 如果每一个开发人员拿到需求以后，都重新实现一次查询、分页、筛选、Loading、异常处理、权限控制，那么不仅开发效率低，最后每个人写出来的东西也很容易不一样。 所以我们会把这些已经反复出现的问题抽象掉。 一个...

最近，我开源了一个本地优先的密码与令牌管理器：KeptNear。 最初开发它的原因很简单：我想要一个交互友好、真正由用户控制数据的本地密码管理器。 后来，在使用 Codex 处理越来越多实际工作时，我发现了另一个问题： Agent 也开始需要凭据了。 GitHub Token、API Key、数据库密码、云平台 Access Key……这些凭据通常散落在环境变量和配置文件里。Agent 需要时要反复配置，也容易在后续任务中遗忘。 更重要的问题是： Agent 为了完成一项操作，真的需要知道凭据本身吗？ Agent 需要的可能不是秘密，而是能力个人密码管理器主要围绕人设计：保存密码、自动填充、复制到剪贴板，然后由人决定何时使用。 但 Agent 不只是读取信息，它会执行 CLI、调用 API，并操作外部系统。传统做法通常是先把 Token 交给 Agent，再由它完成操作： 1Token → Agent / Tool → HTTP Client → External Service 这会让 Token 进入更多不必要的路径，例如 Agent 上下文、Shell 环境、调试日志...

关于人与 AI 的认知连续性 长期使用 ChatGPT 后，我逐渐感受到一种过去使用其他工具时很少有过的体验：它不只是在记住我，还开始沿着我的思路思考。 我曾经把同一个问题分别交给 ChatGPT 和直接调用的 GPT API。两边使用的都是能力很强的模型，得到的结果却明显不同。 API 给出的回答并不差，但更像一个面向任何人的通用答案。ChatGPT 的回答却能接住我真正关心的问题，沿用我习惯的分析方式，并把一个刚刚产生的想法放回过去反复讨论的脉络中。 有时，它甚至能够使用我的思维逻辑帮助我分析问题，写出一篇与我过去表达高度一致的文章。只看最终文本，已经很难简单判断它究竟是由人写的，还是由 AI 写的。 这让我意识到，ChatGPT 所延续的可能不只是一些关于我的信息。 它正在依据长期对话中反复出现的特征，形成一个关于“我可能如何思考”的模型。 在目前的 AI 产品中，ChatGPT 可能是对人的认知连续性做得最好的一个。但这种连续性并不总是稳定。 它有时能够准确延续我的思路，有时却会保留某个结论，而遗漏这个结论形成的条件；它能够识别一个相对稳定的我，却未必总能及时理解一个...

最近一年，我一直高强度使用 Codex、Claude Code 等 AI Agent 来参与日常开发。 刚开始的时候，我和很多人一样，总想着不断给 Agent 增加能力。 遇到一种任务，就增加一个 Skill；发现一条规则，就写进 AGENTS.md；做完一次复杂排查，就想着沉淀下来，方便以后继续使用。 当时觉得这样会越来越智能。 后来我发现，事情并没有那么简单。 Skill，不是越多越好我现在越来越少创建 Skill，也越来越克制使用 Skill。 不是因为 Skill 没用。 恰恰相反，是因为 Skill 很有用，所以更应该慎用。 每加载一个 Skill，本质上都是在告诉 Agent： 除了当前任务，你还需要额外关注这些规则、流程和约束。 如果当前只是一次代码阅读、一次简单修改，或者定位一个问题，这些额外的信息很可能不会帮助 Agent，反而会稀释当前任务真正需要关注的内容。 很多时候，不使用 Skill，Agent 本身已经能够很好地完成工作。 上下文不是越多越好后来我慢慢养成了一个习惯： 如果当前任务没有明确需要，就不要提前加载。 以前，我总觉得多读一点总没坏处。 后...

很多时候，我们以为自己是在解决问题。 但更真实的情况可能是：我们正在一个已经被组织好的问题里努力。 比如一次项目延期，表面看是“有人没有按时交付”。于是我们很自然地开始追问：谁负责？谁拖了进度？下次怎么避免？ 这些问题当然有意义。但如果只停在这里，我们看到的只是内容层。再往深处看，延期背后可能是职责边界不清、需求变化没有入口、资源承诺与实际能力不匹配，或者团队默认把不确定性压给最后一个环节。 这时，问题就不再只是“谁没做好”，而变成了： 这个问题是如何被结构制造出来的？ 这正是 JanusPath 最初想处理的东西。 一、不要只问发生了什么，还要问它为什么以这种方式发生在 JanusPath 的第一篇论文 The Janus Path: A Structured Cognitive Model 中，核心命题可以用一句话概括： 结构先于内容。 也就是说，我们看到的事件、观点、冲突、选择，往往不是孤立出现的。它们背后有一套关系、边界、位置、张力和反馈机制，正在规定什么会被看见，什么会被忽略，什么会被当成自然。 一个会议争吵，内容层看是情绪冲突；结构层看，可能是权责不对等。 一个产品失...

最近，我在使用 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 在短任务中表现很好，但在长流程中会出现一个明显...