AI 没有智慧，你也不会有了
文章批评'不再读代码、不再写代码'的行业风气。作者指出代码可维护性和好架构难以即时度量，其恶果需要数月甚至数年才显现，而有经验工程师依靠长期实践积累的直觉来嗅出代码异味。AI 因缺乏可度量的奖励信号，无法理解什么是可维护的代码，且从质量低劣的野生代码中学习模式，在简化代码、定义可复用函数上表现糟糕。更危险的是，依赖 AI 写代码和读代码的开发者将永远无法达到精通，因为他们不再从错误中学习。作者认为 LLM 只是工具，预言未来会有公司以'无 AI'政策作为竞争优势。
相关文档
/src 里的 Markdown：Markdown 正在变成源代码
htmx 作者、Montana State 大学教授 Carson Gross 提出：在 agent 式编程时代，Markdown 正从文档演变为源代码。他认为 LLM 生成的代码不应只源自用完即弃的提示词会话，而应将捕捉系统意图的 Markdown 签进 /src，与生成代码放在一起。Markdown 具备可 diff、可 grep、人机皆可读写的优势，且遵循局部性原则，让代码模块自带解释其意图的文档。作者提议建立 /src/md 目录约定（含 README、OVERVIEW、features、data、api 等），由人撰写维护，代码与测试从这些 Markdown 派生，测试负责自动化验证正确性。当代码越来越便宜，真正有价值的是代码背后的意图，应将其持久化于源码目录之中。
How I work with Agents
Thorsten Ball 分享了 2026 年 10 月他与 AI Agent 协作的工作方法：使用最新最强的模型，不必担心代码库积累 slop；提示时描述 What 而非 How；让 agent 贯通整个软件开发生命周期（运行、部署、看日志、处理 bug 报告），并为其提供定制工具；通过盲测实验评估 agent 对代码库知识的利用；不要手动管理上下文，让 compaction 工作；请求不可反驳的证明（端到端演示、前后对比数据）；拥抱异步工作流，给 agent 更大任务；利用定时唤醒等自动化功能；只审查高影响范围的代码。这些实践展示了 agent 驱动开发的新范式。
Thinking in Systems, Shipping in Loops
文章引用 DHH 的观点指出，手写代码对绝大多数程序员已不再经济，软件工程正演变为系统架构设计。通过 Artemis 和 SpaceXAI Grok 团队的案例，说明工程师如今通过设计验证循环（verification loops）让 AI 大规模正确地编写代码——如 Lauren Tan 每月发布 2000 个 PR。文章借鉴 Donella Meadows 的系统理论，提出优秀系统设计的三大特性：韧性（AI 通过测试、审查代理和生产可观测性自我校验）、自组织（循环学习将失败类型转化为新技能）和层级（将技能、工具与沙箱组合成可复用组件）。工程师的新职业是'驾驭智能'。
Running a Software Factory Efficiently at Uber Scale
本文介绍 Uber 如何在软件开发生命周期中高效运行 AI 软件工厂。目前 Uber 超过 70% 的 PR 由本地或云端 agent 完成，工程师构建了 3600+ 个 agent 技能，每天执行超 3 万次。文章提出软件工厂的四层 agent 使用架构，并将成本分解为六个可独立测量和优化的因子。通过基于真实工作构建的基准测试进行 Pareto 最优的模型选择、将子 agent 默认路由到更经济的模型、自动上下文压缩等优化手段，Uber 在模型不变的情况下将每千次请求成本降低约 34%，单会话成本较峰值下降 52%，实现了规模化的 AI 工程效率与成本控制。
万字长文｜Claude Code 从入门到实战高手
作者将上万字的大厂 Claude Code 工程化手册浓缩为 23 条实战铁律，涵盖工具定位、入口选择、Git 快照、只读分析、区分事实与推测等基础操作，以及 Read-Plan-Implement-Verify-Review-Deliver 的核心工程闭环。文中详细讲解需求工单化、权限规则优先于提示词、CLAUDE.md 精简配置、长会话压缩与任务拆分、Git 安全红线与安全五不原则，并给出翻车急救包和高级能力升级路径，强调改动必须可解释、可验证、可审查、可回滚。
成为 AI 原生工程师的实践指南
本文探讨了尽管 AI 生成了大量代码，为何工程团队仍面临更多 Bug 和技术债的问题。作者 Shah Rahman 提出，工程师需从单纯的代码编写者转变为编排者，并介绍了成为 AI 原生工程师的四大核心实践：同步上下文工程、规范驱动开发、关键验证以及问题分解，旨在帮助工程师在 AI 时代实现真正的生产力跃升。
认知投降：AI 辅助编程中的隐形成本
文章探讨了软件开发中的“认知投降”概念，即工程师无脑接受 AI 输出而不进行独立思考。这与有益的“认知卸载”形成对比。作者引用实验指出，73% 的人会盲目接受错误的 AI 答案。这种现象会导致代码质量下降、技术债累积以及对系统理解的缺失。文章建议工程师应通过建立预期等启发式方法，在利用 AI 效率的同时保持独立判断，避免陷入理解赤字。
99% 开发者误解的 Claude 技巧：从对话到系统
文章指出了大多数开发者在使用 Claude Code 时仅停留在“对话”层面的误区，提出了将其视为“可编程推理引擎”的理念。作者详细阐述了如何通过构建“输入层-推理层-执行层-反馈层-记忆层”的系统架构，利用 Prompt Builder、自动化测试闭环和 CLAUDE.md 记忆机制，将 AI 从辅助工具转化为高一致性的生成系统。
我使用 Claude Code 的七大技巧（一定有你没看过的）
文章分享了作者在公司内部分享中总结的七大 Claude Code 使用技巧。核心内容包括：使用 Plan 模式先规划后编码；通过 Claude.md 自定义指令与懒加载上下文；利用自分形与自描述机制优化代码搜索与理解；编写清晰提示词；利用 MCP 进行精准检索；使用 Agent 协作与 SubAgent 节省上下文；以及将常用流程沉淀为 Skill。文章旨在通过这些进阶技巧提高开发效率与代码质量。
像 Claude Code 团队一样做代码审查
文章介绍了 Anthropic Claude Code 团队的代码审查实践，以及作者团队自研 AI 代码审查工具 HeyDeer 的落地经验。核心思路是：AI 写代码占比接近 100% 后，人工逐行审查不再可行，应把人的注意力留给真正有风险的部分。做法包括按风险分级审批（低中风险由 AI 自动批准，高风险由人判断方向）、多模型交叉审查降噪、用仓库检查落实团队规范、通过 Autopilot 自动修复问题直至收敛。作者团队跑了 8 个月未因合并有 bug 的代码导致线上事故，认为大部分创业和中小公司都适用这种方式。
Claude Code 团队如何进行代码评审
本文介绍了 Claude Code 团队在 AI 生成约 90% 代码的情况下如何重构代码评审流程。团队将代码评审从人工逐行阅读转变为分层自动化体系：包括 PR 前的 Claude 自验证、子代理 diff 审查、内部 skill（bug 猎捕、diff 缩减等）、以及每个 PR 的 AI 评审，仅将人类注意力保留给高风险决策。通过 CLAUDE.md 和 REVIEW.md 等文件向评审者注入项目上下文，并快速回滚机制兜底。6 月至 9 月间合并 PR 数量翻倍，回滚率下降超 40%，实现了用最少人工环节保障代码质量的目标。
How to organise a project's knowledge for AI coding agent and an engineer
作者分享了在咨询项目中管理项目知识库的方法，旨在同时服务 AI 编码代理和工程师两类读者。核心设计是对一棵 Markdown 文件树执行五种操作：存储（将原始资料、事实和生成产物分目录管理）、创建（新资料经过切片、摘要、生成视图和规范的固定流水线）、更新（通过哈希检测变更，沿链接反向重建所有依赖产物）等。设计强调每个摘要、视图和规范都链接到其来源事实，配合两条质量护栏确保生成内容有据可依，使文档变更后系统能自动同步更新所有下游内容，为编码代理提供始终最新的详细规范。
