- 博客(1063)
- 资源 (21)
- 收藏
- 关注
RSS订阅
原创 Ledge：这可能是距今最好的『DevOps + 研发效能』知识平台
过去的三星期里，因为疫情 + 种种不可告人的原因，我开始建设一个 DevOps 知识平台。GitHub：https://github.com/phoda...
2020-03-30 20:58:00
2098
1
原创 无代码编程
中台之后，便是无代码编程。规模化的组织，经常要面临这样的挑战：每个应用的基础设施是相同的，部分的代码也是相同的，甚至于它们可能只是数据模型不同而已。结果却导致了，他/她们要一次又一次地重新编写一个应用。对于一个新的应用而言，它需要对接大量的三方（非自己团队）服务。服务之间的不断变化 ，导致了对应的使用方也需要发生变化。不断变化的业务，导致了前台的设计不断变化。为了应对快速谈的的前台服务，后...
2019-04-02 09:05:27
15972
16
原创 致JavaScript也将征服的物联网世界
凡是能用JavaScript写出来的，最终都会用JavaScript写出来。—— Atwood定律在那篇《最流行的编程语言JavaScript能做什么？》里，我们列举了JavaScript在不同领域的使用情况，今天让我们来详解一下JavaScript在物联网中的应用。基础：物联网的三个层级开始之前， 先让我们简单地介绍点物联网的基础知识。如果你有点Web开发经验的话，都知道下图是CS架构：相比于一
2016-08-07 22:14:26
33250
10
原创 从复杂编辑器到 Agent 工作台：Office 的 Cursor 时刻
这些工具的差异很大，但共同结构很清楚：人不一定先打开文件、定位函数、手动改几行，而是描述目标，让 Agent 修改一组文件，再通过 差异对比、测试结果、运行日志和评审流程判断是否接受。因为我已经有一个技能可以生成幻灯片、XLSX 和 DOCX，所以我最开始 只是想把 DOCX、XLSX、PPTX 打开，能预览、搜索、缩放，未来可以更方便添加更多的功能。编辑不是重新生成一份文档，而是在已有现场里工作：当前页面、文字层级、图片位置、图表数据、演讲备注， 以及用户选中的对象，都会影响 Agent 接下来怎么改。
2026-05-24 10:53:14
531
原创 /canvas：不止是更漂亮的输出，而是下一代人机协作
它应该能够成为下一次行动的入口。我们不只是给 Agent 一个可以渲染 React 的画布，而是希望它在生成界面时，能从 Qoder 当前代码库、SDK 类型、Design Tokens 和 recipe 中理解：在这个产品里，界面应该怎样被设计。所以，面向 Agent 的 Design System，不能只是把组件库暴露出去，而是要把团队的设计经验变成机器可读的上下文：组件适用边界、推荐组合、设计 token、布局模式，以及那些代码里真实发生过的产品判断。Chat 还在，代码、Diff、测试也都还在。
2026-05-21 11:36:18
574
原创 注意力 Harness：多 Agent 时代如何守住人的注意力
于是，多 Agent 时代的核心问题不只是“如何让 Agent 更能干”，而是如何为人的注意力设计一套 Harness：哪些事情应该打断人，哪些应该静默推进，哪些需要聚合，哪些必须升级。但当 Qoder、Codex、Claude Code 这类工具开始支持长任务、后台执行、多线程会话、权限请求和结果审查后，真正的难点变成了：多个 Agent 同时工作时，人类如何看住它们。但在 Agent 时代，每一条消息背后都可能有一个正在运行的任务、一个待批准的命令、一个缺失的证据，或者一个失败的验证门禁。
2026-05-17 18:44:43
576
原创 AI 解决繁杂任务：从 /goal 到长时间异步 Agent 运行
这个 loop 里必须有计划，有验证，有权限边界，有日志，有 checkpoint，有人类可以中途插手的位置。这类能力真正该去的地方。很多人讨论 Agent 时盯着模型能力，真正让长任务能跑下去的，反而是那些很普通的东西：README、PLAN、progress、artifact、test report、git log。围绕这几个目标，最后最重要的事反而不是盯着模型怎么写代码，而是写 spec，设边界，设计验证，拆 checkpoint，看报告，决定哪些状态要写回 README，哪些失败要留给下一轮。
2026-05-10 23:18:13
566
原创 任务自适应 Harness：从 Trace 到多 Coding Agent 的协作记忆
毕竟单条 Trace 的价值有限，真正有价值的是多条 session 之间反复出现的关系：某个功能经常访问哪些文件，某类任务总是调用哪些工具，哪些文件是 Agent 反复读取的热点， 哪些路径经常出现在失败之前。3. 一次委派结束之后，系统留下来的也不只是可供回放的 trace，而是一份可以交接的状态：前面试过什么，哪些路已经走不通，哪些地方还不确定。同样是历史上下文，不同角色需要看的东西其实不一样。它不预设固定环境，而是在任务开始前，根据目标、证据、历史和约束，收缩出这一次真正需要的上下文、工具和规则。
2026-04-22 16:13:23
653
原创 从写清 Spec 到看懂功能：在 Session 历史中使用 Routa 重建需求全景
Spec 仍然负责边界、约束和验收，但大量真正改变实现走向的内容， 已经留在 Codex、Claude Code、Qoder 这些 Agent 的 session 历史里：一次失败的尝试，一个临时收掉的交互，一次 API 结构调整，一组被反复读写的文件。但 Session 的问题也同样明显。所以我后来关心的事情也跟着变了：session 里的局部过程能不能重新推回当前功能，Spec、页面、API 和实现文件的关系能不能稳定下来，Agent 能不能先面对一份围绕 Feature 收拢过的证据，再去做分析。
2026-04-20 15:44:45
574
原创 Routa 桌面版发布：内建 Harness 工程的 AI Coding 研发协作工作台
于是，围绕 Routa，我逐步长出了几组关键部件。但更重要的是，它还是一套内建了质量门禁、阶段约束和领域专家的任务状态机： 卡片进入哪一列，不只是状态变化，也意味着系统开始按另一组规则检查这项工作是否具备继续推进的条件。其中，Coding Agent 提供的是执行能力，Kanban 提供的是任务状态，Harness 工程提供的则是约束、验证和完成定义。它更像一条持续推进的流：需求进入系统，任务被拆开，阶段向前滚动，不同角色在不同位置接手， 结果被验证、退回、重试，最后只有一部分穿过门禁进入交付。
2026-04-14 15:51:34
720
1
原创 Harness Monitor：当多个 Agent 同时写代码时，如何看住质量
它更像是在做一件很小、但很现实的事：把多 Agent 并行开发重新接回到一个可观察、可验证、可治理的闭环里。它不是先从什么宏大的架构治理概念开始，而是从 Git 视角里一个很朴素的问题一点点长出来的：先回答“谁改了什么”，再回答“这些改动意味着什么”，最后才走向“这次改动是否具备继续推进的质量条件”。当多个 Agent 同时在一个仓库里写代码时，最先需要回答的，往往不是复杂的治理问题，而是几个非常具体的问题：哪些文件变了，变了多少，工作区是不是已经 dirty，这些变化大概率属于哪个会话。
2026-04-13 11:43:50
572
原创 Agent 看板门禁：构建 Agent Team 的 Harness 工程防御体系
可一旦 Agent Team 开始跨实例、跨 worktree、跨 provider 运行，真正保护系统不失控的，往往不是更聪明的 prompt，而是这些看起来不那么性感的约束：谁拥有这个 session，谁可以恢复，什么时候系统必须明确拒绝恢复。一支 Agent Team 真正难的，从来不是把任务“做完”，而是把“完成”拆开：任务完成，证据完备，会话可恢复，交付可归档，这几件事在单人开发里经常被默认等价；换句话说，卡片可以 Done，交付可以归档，但这不等于绑定的进程上下文还可以被任意接管。
2026-04-09 18:06:49
693
原创 /phodal-writer：如何把十年写作经验整理成一个 Skill
所以，这里真正值得强调的，并不是目录好不好看，而是 Skill 的组织方式本身就在表达一个判断：能力封装不只是把知识放进去，还要把知识按使用时机组织出来。它采用的是工程方法论型原型，开头从实践冲突切入，中段完成问题重命名，后面依次展开模式提取、规则转译和结构设计，最后再把讨论收束到“经验封装”这个更大的命题上。这件事的起点很现实。我的文章里，真正起到收束作用的句子，大多都在段末或节末，而且句式也相对稳定，比如“换句话说，……我要它回答的，也不是“你的文章像什么”，而是一组更具体的问题：我的开头通常怎么起？
2026-04-08 17:04:32
613
原创 从 Rule、Spec 到 Harness：AI Coding 的渐进式建设路径
OpenAI 近期总结 Codex 的长任务经验时，也把 loop 明确写成 plan、edit code、run tools、observe results、repair failures、update docs/status、repeat，并强调长任务之所以更可靠，不在于一个更长的 prompt，而在于 harness 提供了结构化上下文和清晰的 "done when" 例程。所以，我们要建设的不是一条"让 AI 写更多代码"的路径，而是一条"让 AI 在工程体系里稳定完成交付"的路径。
2026-04-07 16:52:58
475
原创 Harness 工程可视化：在 Vibe Coding 中重建工程可控性
好的治理，不是把资深工程师的判断力替换掉，而是把它沉淀成系统能够反复调用的能力。这些反馈并不缺席，它们其实一直都在，只是在大多数仓库里，它们是分散的、割裂的，很少被当成一个整体来理解。哪些阶段是被治理覆盖的，哪些其实是裸露的路径。否则，再完整的治理机制，也很容易退化为分散的配置、隐性的约定，以及只能依赖经验维持的工程实践。你不需要再翻一堆文档，也不需要去问最熟悉仓库的那个同事，就能大致看出系统哪里是实的，哪 里是空的。只要规则是结构化的，控制点是可触发的，反馈是可解析的，它就能够在局部决策中持续运行。
2026-04-03 11:12:21
510
原创 Harness 工程 Skill：使用 Entrix 技能开始你的代码熵治理
这样一来，Entrix 在 Routa 中就不再只是一个 CLI，也不再只是仓库中的若干规则文件，而是同时成为可执行的规则源、Agent 可消费的上下文，以及团队可以共同浏览和讨论的治理界面。规则第一次不只是“存在”，而是既能被执行，也能被解释，还能被团队直观看见。Entrix 不是一个单纯跑检查脚本的工具，也不是把已有 lint 和 test 再包装一层，而是试图把仓库中原本分散的质量规则、完成条件和升级路径，收敛为一套可以执行、可以理解、也可以被可视化的 Harness Engineering 结构。
2026-03-30 23:12:50
584
原创 从 0 到 25 万行：一个 100% AI 编码项目，真正难的不是生成，而是治理
一旦关系从“工具”变成“队友”，问题就不再是它能不能产出代码，而是它能不能进入项目的协作系统：它有没有明确边界，是否遵守当前规则，写出来的东西是不是还落在共享契约之内，失败后能不能被及时拉回，这些失败又能不能继续沉淀成更稳定的 Harness Engineering。）把这件事真正展开。所以，对 Routa 这样的项目来说，最值得讲述的并不是“25 万行代码由 AI 写成”这个结果本身，而是这个结果背后的工程判断：团队并没有把 AI 当成一个更快的代码生成器，而是在持续把它纳入一个越来越严密的反馈系统中。
2026-03-24 22:30:38
445
原创 Entrix 开源了：我们如何用反熵机制治理 Vibe Coding
代码变多了，绿灯变多了，提交变密了，但工程系统对“这次改动到底安不安全”的判断，并没有一起升级。这件事的意义，不在于 Markdown 比 YAML 更优雅，而在于它改变了知识的存在方式。里，让系统不只是“跑几条命令”，而是开始承认哪些信号算 hard gate，哪些该按 tier 分层运行，哪些变化该触发人工 review，哪些检查只应该在 changed-only 场景里执行。你给出一个目标，AI 很快补全代码、修掉报错、加几条测试，终端持续吐出绿色信号：编译通过了，接口通了，页面能点了，测试也过了。
2026-03-20 21:50:55
413
原创 AI 编码 3.0：人机协作，正在走向多 Agent 协作系统化
它通过一组可执行约束，将原本依赖经验判断的过程，转化为可验证的工程行为，使系统从“看起来没问题”转向“被证明可以通过”。问题并不是一开始就显性的，相反，它们往往出现在那些我们过去从不认为需要被建模的“边角”位置：卡片究竟在什么条件下才允许移动，如果当前列中仍然存在未完成的执行步骤，是否还应该允许进入下一列，当 Agent 执行失败时系统应该停留、重试还是回退，这些问题在人类主导的协作体系中通常不会被精确定义，因为团队会通过经验、语境和即时沟通不断修正这些决策，甚至不会意识到这些决策本身的存在。
2026-03-19 21:22:05
428
原创 Harness Engineering 实践：Fitness Function 如何成为 AI 交付的防腐层
但在 Agent Loop 中，这个默认前提不再成立。提供入口导航，用 Markdown frontmatter 声明规则，用证据文件记录验证状态，用统一执行器收敛规则解释，用契约检查约束多实现一致性，再通过 hooks 与 CI 把这一切接入交付链路。因此，当 Harness Engineering 真正落地时，它面对的下一个问题并不是如何生成代码，而是如何把“完成”这件事，从经验判断转化为。系统不再接受“这次应该问题不大”这样的模糊表述，而只接受规则中声明过的命令、可观察的输出，以及明确的门禁结果。
2026-03-16 22:57:22
716
原创 当 Kanban 不再管理人：Routa Kanban 如何管理 Agent Team
此时，最关键的信息不是某个 Agent 刚刚说了什么，而是哪几张卡正在运行，哪几张卡还在等待，当前并发上限是多少，哪些工作因为资源压力被延后。这篇文章想讨论的，不只是一个看板页面，而是一种新的工程判断：在 AI4SE 时代，如果我们希望多 Agent 协作真正进入日常软件交付，就必须同时建设管理界面与工程护栏，而不是只建设聊天能力。因为在 AI4SE 的下一阶段，真正决定系统能否进入日常生产的，往往不会是某次惊艳的代码生成，而是这套系统是否已经具备了被团队管理、被组织信任、被工程约束长期守护的能力。
2026-03-15 15:23:35
323
原创 Harness Engineering 的防御视角：从 Codex Security 看 AI 生成代码的治理
在代码层面，扫描依赖的是静态分析与数据流追踪的结合。分析会从典型输入源开始，例如 HTTP 请求参数、RPC 调用或 URL 查询字符串，然后沿着代码路径追踪数据的传播过程，直到抵达危险操作，例如 shell 执行、HTML 渲染或外部网络请求。与传统的安全扫描不同，这些报告不仅包含漏洞列表，还提供了完整的攻击路径、动态验证结果以及可应用的修复补丁。从 Codex Security 的扫描分析中得到的最大启发，并不是 AI 让软件变得更危险，而是 AI 让工程系统中长期存在的问题变得更加明显。
2026-03-12 22:14:50
485
原创 AI Coding 流畅度模型：人机协作中的开发者角色转型与未来演进
阶段，团队主要通过对话界面或简单工具使用 AI。通过逐步建立人与 AI 的协作能力，团队可以更好地利用 AI 的潜力，同时保持软件系统的质量与可持续演进。在越来越多的团队中，AI 不再只是提供建议，而开始参与实际开发任务，例如生成模块、运行测试、修复错误，甚至创建 Pull Request。然而，在许多组织中，人们仍然把 AI 编程理解为一种工具升级：更聪明的 IDE 插件、更强大的代码生成器，或者更方便的技术问答助手。从最初的代码补全工具，到能够执行复杂任务的智能体，AI 在开发中的角色正在不断扩大。
2026-03-11 07:56:38
440
原创 从实践到原则：为 AI Agent 构建的 Harness Engineering 落地与探索
例如 Stripe 在其 Agent Engineering 实践中构建了一套完整的执行循环：工程师通过 Slack 或 CLI 触发任务，Agent 负责生成实现代码并运行测试，如果 CI 失败，系统会自动进入修复循环，直到代码满足基本质量标准后再生成 Pull Request。从最初的代码补全工具，到能够生成完整模块的 Coding Agent，再到可以自主修复 Bug、执行测试甚至生成 Pull Request 的智能体，软件开发的生产方式正在发生明显变化。传统的软件工程体系是围绕人类开发者设计的。
2026-03-10 21:53:23
645
原创 2026 年，万物皆 Coding Agent 的平台工程新范式（A2A / ACP / MCP / Skill）
也就是说，Workspace Agent 是“微编排器”，把 ACP Agent 当作可调度的执行单元，而不是自己执行具体代码。当每个 DevOps 环节都长出自己的 Agent，孤岛化问题显而易见：工具多、重复多、效率低。通过任务拆解、Agent 调度、事件同步和状态管理，零散的 Agent 被组织成链条：规划者规划，实现者实现，验证者验收，每个角色都有 Skill 明确能力边界。Skill 的 Agent 明白了，你的意思是：Workspace Agent 并不是单进程独立做任务，而是一个。
2026-03-03 12:03:30
975
原创 Agent Team 实践与架构设计：在约束下构建可演进的一个人开发团队
在没有公司完全买单的 Cursor 之后，我需要一种更好的方式，能在一个月非常好地利用、编排工具，这样的话 Kiro + Copilot 提供的 Opus/Sonnet，就能发挥最大价值 —— 当然要我说最好用的还是 Augment Code，但是只是 backup，Claude Code 虽然强，但是上下文的。的技术专家，我一直相信，可演进性才是我的竞争力，也是构建系统的核心 —— 尽管，供应商绑定（Vendor Lock-in） 也是一个非常“不错”的商业模式，但是那可是屎山。
2026-03-02 16:50:59
602
原创 从 AutoDev 到 Routa：开放生态下的多 Agent 编排新一代实践
这些 Store 提供了 状态持久化能力——如果某个 CRAFTER 陷入死循环（类似 AutoGen 常被诟病的对话混乱），或者发生网络中断，Routa 的架构能够依靠结构化的 Task 和 Stores 从断点恢复执行，而不是从头开始消耗 Token。这展现了 Routa 在企业级部署时对。PS：在设计 Routa，我们（我和 AI）参考了 Augment Code 的 Intent 协作体系、JetBrains 的 ACP 管理、Claude Code 的 MCP 管理、Codex 的交互等。
2026-02-24 15:56:27
635
原创 ACP 协议 + 多 AI 编程智能体：企业研发的新生产力平台
你可以在 IDEA 中集成各类 Coding Cli 工具，而这些工具可以与 IDEA 的生态进行深度融合，他可以是支持 ACP 协议的 OpenCode、Auggie 等，也可以是不支持 ACP 协议的 Claude Code 等 —— IDEA 会帮它们支持的。在传统的 AI 编码助手中，Agent 往往是一个"黑盒" ——你发送一个请求，等待一段时间后得到结果，但中间发生了什么、Agent 读取了哪些文件、修改了什么代码，这些过程对 IDE 和用户来说都是不可见的。，彻底解决了这个问题。
2026-02-09 15:48:11
1357
原创 平台工程视角下的 AI 应用架构治理：从碎片化 AI 到规模化智能
在实践中，AI 最容易走向失控的地方，往往出现在业务侧。等专业工具，不仅看流量，更要看 Prompt 的演进、会话上下文（Sessions）以及跨多步推理的 Trace 细节。一个反复被验证的事实是：AI 在生成和重构上极其高效，但在责任、风险和长期演进上，仍然需要工程体系兜底。很多组织以为，AI 的挑战在于模型选型、参数规模，或者“要不要自建平台”。：根据任务复杂度、成本、时延 SLA，将请求分发至不同的模型（小模型优先原则）。AI 架构治理，并不是在讨论“是否要做一个 AI 平台”。
2026-02-05 22:35:00
421
原创 AI 时代的洞察方法论：结构化思维与能力迁移
在过去，我们去构建这样一个数据原型成本巨高，特别是数据领域有大量的工具，操作型数据、流式数据、 CD4ML、数据质量、数据目录等等。为了达到预期的 Thoughtworks DPS（数字化平台策略），我们做了大量的人肉搜索：查阅高盛的博客、年报、技术网站、技术高管访谈，甚至浏览他们的 GitHub 仓库。我很快让 AI 开始分析，同样的目标、同样的素材，结果几乎在短短几十分钟内就完成了大部分信息整合——果然不出我所料，底层重复性的工作可以完全自动化， 而我可以将精力放在更高阶的思考上。
2026-01-19 22:49:48
770
原创 ＜span class=“js_title_inner“＞AI 时代的洞察方法论：结构化思维与能力迁移＜/span＞
在过去，我们去构建这样一个数据原型成本巨高，特别是数据领域有大量的工具，操作型数据、流式数据、 CD4ML、数据质量、数据目录等等。为了达到预期的 Thoughtworks DPS（数字化平台策略），我们做了大量的人肉搜索：查阅高盛的博客、年报、技术网站、技术高管访谈，甚至浏览他们的 GitHub 仓库。我很快让 AI 开始分析，同样的目标、同样的素材，结果几乎在短短几十分钟内就完成了大部分信息整合——果然不出我所料，底层重复性的工作可以完全自动化， 而我可以将精力放在更高阶的思考上。
2026-01-19 22:49:48
609
原创 AI 编程 2025 总结：国产模型“能力追平”，国产编程工具还在“情感陪伴”
你甚至可以在“官方的文档”上看到大量的相关文档，它展示着如何利用开源的 Cline、Gemini，还有闭源的 Claude Code 使用国产的 19.9 元的 Coding Plan。另一个更明显的信号，来自 Code Review 场景。PS：大家需要注意的是，虽然我们看到在榜单上各种模型的分数相当的高，但是受限于基础模型在语料上的不足，并非所有的场景，都能达到很好的效果。尽管，在某些复杂任务上的表现不足， 如我之前设计的遗留系统迁移场景，在长对话后，模型完成的任务有点失焦，但是总体表现还是不错的。
2025-12-30 16:27:01
1734
原创 我的 2025 总结：当 AI 开始释放创造力，工程师如何重新站位
他（Phodal）所构建的 Xiuper 生态，不仅仅是一套工具，更是一种对未来软件开发方式的预言：未来的开发者将不再是单纯的“打字员”，而是智能体战队的“指挥官”。但是，它生成不好足够的 insights，尤其是对于复杂的技术细节和长期的项目演进。但是，对于实现某些特定的任务，它所带来的提升是巨大的。只是 AI 并不是只提升了生产力，与此同时它降低了我创作的欲望，它生成东西的速度实在是太快， 以至于通过我在构思完大纲之后，会很快失去继续写下去的动力，只想交给 AI 去完成剩下的部分。
2025-12-29 18:13:09
677
原创 Agentic UI：重新定义“好体验”——不是美化按钮，而是让认知负担归零
这一转变要求前端的角色必须进化：从传统的“展示界面”（GUI），演变为一个可执行、可治理、可审计的“工作界面”。从快速自我迭代、“不需要看代码”的 Claude Code，到 Agent 模式的 AI IDE（如 Google Antigravity），Agent 的进化速度已经远超传统 UI 架构的迭代。AI 原生架构的关键不在于“让模型更会写 UI”，而在于通过 DSL、编译与评估机制，把 UI 生成变成一条可验证、可度量、可回归的工程闭环——这才是 IDE 场景真正可交付的 AI 产品能力。
2025-12-23 20:58:17
688
原创 AutoDev 3.0 → Xiuper：咻！全平台、全流程智能体编程平台
覆盖从需求分析、代码编写、文档管理到代码审查的完整开发流程，并且支持 Desktop（macOS/Windows/Linux）、CLI、VSCode、JetBrains IDE、Web、Android 和 iOS 全平台运行。从需求理解、架构设计、代码实现，到测试验证、文档编写、代码审查，乃至 UI 调整和团队协作，Xiuper 的每一个 Agent 都对应真实工程角色，实现完整的。（SDLC），每一个阶段都由专门的智能体（Agent）支持，从需求理解到运维管理，形成完整的。
2025-12-14 20:13:21
981
原创 AutoDev DocQL：Agentic RAG 下的结构化检索设计、实现与实验探索
在 Agent 流行的今天，Agentic RAG 并不是一种新的技术， 我们在 Cursor、Claude Code、Antigravity 等中看到的 Agent 在接受用户的输入之后， 做了一系列 read file、grep、codebase 等操作本身，就是 Agentic RAG。既然，我们在 AutoDev 多端版本中已经构建了多个 Agents，那么再构建一个新的 Agent 难度自然也是不大的，这也就是 AutoDev Knowledge 的想法，试验用于复杂场景下的知识问答。
2025-11-28 07:30:47
977
原创 AI 代码审查再进化：AutoDev 多智能体协作架构深度解析
CodeReviewAgent（主 Agent）/执行整体任务编排，负责 diff、lint、issue、测试等多源信息的聚合。AutoDev 智能审查流程可以概括为一个串联的四步流水线：先收集全部静态上下文，再用 LLM 做深度分析，然后生成可执行的修改计划， 最后由多 Agent 协作完成自动修复。等长期痛点：Lint、测试、Issue、变更记录散落在不同系统里；，AutoDev 让 AI 像资深工程师一样，能够全面理解代码的上下文、历史演进、质量风险，并在必要时自动生成修改建议或直接执行修复。
2025-11-26 17:40:22
638
原创 AutoDev Review Agent：应对 10 倍代码量的 Agentic 代码审查
自然而然的，我们做一个关于 Code Review 的研究，肯定不是为了好玩，所以在这一篇文章里， 我们将介绍 AutoDev 的新 Agent，基于多端架构的 SubAgents 体系的 Code Review Agent。只是对于核心的软件开发系统来说，Code Review 是非常有必要的，可以改善质量，毕竟要花费大量的时间。现在的软件往往有着非常复杂的软件架构，诸如于多系统集成的微前端应用，小程序化的移动应用，还有不合理微服务架构的后台应用，他们往往是由成十上百个 子仓库或者系统集成的。
2025-11-17 12:23:22
701
原创 ＜span class=“js_title_inner“＞AutoDev Review Agent：应对 10 倍代码量的 Agentic 代码审查＜/span＞
自然而然的，我们做一个关于 Code Review 的研究，肯定不是为了好玩，所以在这一篇文章里， 我们将介绍 AutoDev 的新 Agent，基于多端架构的 SubAgents 体系的 Code Review Agent。只是对于核心的软件开发系统来说，Code Review 是非常有必要的，可以改善质量，毕竟要花费大量的时间。现在的软件往往有着非常复杂的软件架构，诸如于多系统集成的微前端应用，小程序化的移动应用，还有不合理微服务架构的后台应用，他们往往是由成十上百个 子仓库或者系统集成的。
2025-11-17 12:23:22
436
原创 2025 AI 代码检视：以 ROI 为中心的 AI 代码检视体系与智能体架构设计
昨天，和我的前同事（他们 Thoughtworks Global，我们前 Thoughtworks 中国区，现 Inspire）聊完 AI Code Review 之后，觉得有几个点非常不错 的点，应该会影响到不少人对于对 AI 代码检视的架构设计与思考。简单来说，如果你要 review 10 行代码，那么我从我的上下文工程中，应该获取到 10 行的上下文信息， 诸如于：用户意图、文件依赖关系、预期结果。在足够的 context 能影响结果的情况下，我们的问题就变成了，我们是否值得投入这么多去做这件事。
2025-11-14 12:15:12
954
简单多任务任务高度
2011-11-14
Django 1.0 Template Development
2011-12-27
Android,Bash,终端,Term
2012-02-09
Django Documentation Release1.2
2011-12-27
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人