AI编程实践：从Claude Code实践到团队协作的优化思考｜得物技术
一、开发痛点：为什么我们需要AI编程辅助？核心发现： AI编程工具正在重塑开发流程，但真正的价值不在于替代开发者，而在于构建人机协作的新型开发范式。Claude Code通过精准对话流设计、模块化任务分解和专业化子代理协作，在提升开发效率的同时，也面临着上下文管理、协作边界和质量控制等实际挑战。作为一线开发者，我们每天都在与复杂的业务逻辑和不断迭代的技术栈打交道。不知道你是否也遇到过这些场景：刚理清一个复杂业务流程，被打断后又得重新梳理思路；接手一个老项目，花了半天还没搞懂其中某个模块的设计思路；或者在不同项目间切换时，总要重新适应不同的编码规范和架构风格。日常开发的三个"拦路虎"：上下文切换成本高： 需求理解→技术选型→代码实现→质量验证的切换过程中，每次都要重新构建认知框架。知识传递效率低： 项目规范、架构经验分散在文档和个人经验中，新成员上手或跨模块开发时处处碰壁。开发流程割裂： 需求→设计→编码→审查各环节串行传递，信息易失真且反馈滞后。这些问题不是简单的"加人"或"加班"能解决的。我们需要的是一种新的开发范式，而Claude Code这类AI编程工具正是在这样的背景下进入了我们的视野。它的价值不在于替我们写代码，而在于成为我们的"认知放大器"和"流程协作者"。二、Claude Code核心功能解析：从工具到方法论Claude Code构建了一套完整的AI辅助开发方法论。接下来将结合团队实际使用经验，从功能特性、使用场景和设计初衷三个维度，详细介绍其核心功能：精准对话流设计：控制AI思考的艺术第一次用Claude Code时，就像面对一个热情但经验不足的实习生——如果不明确告诉他要做什么、怎么做、有什么要求，他很可能会给你一个"惊喜"。对话流设计就是解决这个问题的关键。设计初衷： 对话流设计的本质是将人类的编程思维模式转化为AI可理解的结构化交互方式，通过明确的上下文管理和约束条件设置，引导AI生成符合预期的代码结果。核心功能对话流设计通过三个关键机制控制AI的思考过程：上下文聚焦： 要求单次对话仅处理一个功能模块，避免多任务混合导致的AI注意力分散。我们曾经试过在一个对话里同时让AI处理多个模块，结果它把两个模块的错误处理逻辑混在了一起。约束明确化： 通过具体指令减少AI的自由度，比如"仅修改X包下文件"、"必须复用Y工具类"。这些约束要尽可能具体，比如不说"遵循项目规范"，而是说"使用ResultDTO作为统一返回格式，错误码规则参考ErrorCodeEnum"。增量式提问： 采用"先框架后细节"的提问策略，先让AI生成接口定义和整体框架，待确认后再逐步深入实现细节。这种方式很像我们带新人时"先搭骨架再填肉"的指导方法。使用心法启动新功能开发时，我们会创建专用对话线程，并在初始prompt中明确四件事：当前任务的功能边界和目标（做什么，不做什么。）必须遵守的技术约束和规范（用什么技术栈，遵循什么标准。）期望的输出格式和交付物（要代码？要文档？还是两者都要？）分阶段的实现计划（先设计接口，再实现逻辑，最后写测试。）真实踩坑经验处理跨模块依赖时，我们发现AI很容易"忘记"之前设定的约束。后来我们总结出一个技巧：每开始一个新的实现阶段，就简要回顾一下关键约束。比如："现在我们要处理任务交接流程，请记得：1. 使用Redis分布式锁；2. 需要修改商运关系和新商成长任务；3. 异常处理要符合规范。"Plan模式：复杂任务的系统化分解面对"实现一个完整的拜访任务系统"这样的复杂需求，直接让AI生成代码就像让一个刚入行的开发者独立负责整个项目——结果往往是逻辑混乱、漏洞百出。Plan模式就是解决这个问题的"项目管理工具"。现状与问题：我们早期使用Claude Code时，经常犯一个错误：把一个复杂需求一股脑丢给AI，然后期待它给出完美解决方案。结果通常是：实现逻辑不完整，有些边界情况根本没考虑到。模块间接口设计不一致，调用起来磕磕绊绊。技术选型不合理，用了个"看起来很酷但项目中并不适用"的方案。这其实不能怪AI，人在面对过于复杂的问题时也会手足无措。我们需要一种方法把大问题拆分成小问题，而Plan模式正是借鉴了项目管理中的WBS（工作分解结构）思想。我们的解决方案：Plan模式使用三步法分解需求：需求分析与模块划分：把整体需求分解为独立的功能模块。技术方案设计：为每个模块确定实现思路和技术选型。任务优先级排序：根据依赖关系和重要性确定实现顺序。实际操作示例：拜访任务需求拜访任务是一个简单的企业内部任务需求，在实现"拜访任务需求"时，我们通过Plan模式生成的任务清单是这样的：--- 拜访任务线上化 - 模块清单 M1: 任务创建模块 - 功能: 创建拜访任务,包含基本信息、拜访对象、参与人员 - 复杂度: Medium (需要处理多表关联和事务) M2: 任务审批模块 - 功能: 飞书审批流程集成,支持任务提交、审批、驳回 - 复杂度: High (涉及飞书审批接口集成和状态流转) M3: 日程同步模块 - 功能: 将拜访任务同步到飞书日历 - 复杂度: Medium (飞书API调用和异常处理) M4: 任务列表查询模块 - 功能: 分页查询任务列表,支持多维度筛选 - 复杂度: Medium (ES聚合查询和数据转换) M5: 任务详情查询模块 - 功能: 查询任务详情,包括拜访对象、参与人员、商家信息 - 复杂度: Low (简单的关联查询) M6: 任务统计模块 - 功能: 统计不同类型、不同状态的任务数量 - 复杂度: Low (聚合统计) M7: 拜访结果提交模块 - 功能: 提交拜访记录,上传附件,记录拜访内容 - 复杂度: Medium (文件上传和多表操作) M8: 任务分配模块 - 功能: 批量分配任务给运营人员 - 复杂度: High (涉及分配策略和定时任务) M9: 任务触达模块 - 功能: 任务开始、结束、上传提醒通知 - 复杂度: Medium (飞书消息卡片模板) M10: ES数据同步模块 - 功能: 将任务数据同步到ES,支持全文检索 - 复杂度: Medium (事件驱动和ES批量操作) M11: 任务导入模块 - 功能: Excel批量导入拜访任务 - 复杂度: High (Excel解析、数据校验、批量插入) M12: 任务状态变更模块 - 功能: 定时更新任务状态(未开始→进行中→已结束) - 复杂度: Low (定时任务和批量更新) --- 第二步:技术方案设计 | 模块 | 数据存储 | 查询方案 | 外部集成 | |------------|------------------------|------------------|-------------------| | M1-任务创建 | MySQL (事务) | - | - | | M2-任务审批 | MySQL + 审批记录表 | - | 飞书审批API | | M3-日程同步 | - | - | 飞书日历API | | M4-任务列表 | ES (主) + MySQL (辅) | ES聚合查询 | - | | M5-任务详情 | MySQL | 联表查询 | 商家信息API | | M6-任务统计 | ES | ES聚合统计 | - | | M7-结果提交 | MySQL + OSS | - | OSS文件上传 | | M8-任务分配 | MySQL | 分配算法 | - | | M9-任务触达 | - | - | 飞书消息卡片 | | M10-ES同步 | ES | Spring Event | - | | M11-任务导入 | MySQL | Excel 解析 | - | | M12-状态变更 | MySQL | JOB定时任务 | - | --- 第三步:任务优先级排序 P0 核心流程(必须先实现) 1. M1-任务创建 (基础功能) 2. M5-任务详情 (数据展示) 3. M4-任务列表 (核心查询) 4. M7-结果提交 (闭环流程) P1 审批与通知(核心功能增强) 5. M2-任务审批 (依赖M1) 6. M3-日程同步 (依赖M2审批通过) 7. M9-任务触达 (依赖M1、M7) P2 运营功能(效率提升) 8. M8-任务分配 (依赖M1) 9. M11-任务导入 (依赖M1) 10. M6-任务统计 (依赖M4) P3 技术优化(性能优化) 11. M10-ES同步 (依赖M1、M4) 12. M12-状态变更 (独立模块) --- 实现建议 阶段一:基础能力 - 先实现 M1、M5、M4,打通任务创建→查询→详情的基本链路 - 使用 MySQL 实现,暂不接入 ES 阶段二:审批流程 - 实现 M2、M3,接入飞书审批和日历 - 完成任务的完整生命周期管理 阶段三:结果闭环 - 实现 M7,完成拜访结果提交 - 实现 M9,添加任务触达通知 阶段四:运营优化 - 实现 M8、M11、M6 - 提升运营效率 阶段五:性能优化(按需) - 实现 M10,将查询迁移到 ES - 实现 M12,优化任务状态管理这种方式不仅让AI能够有序工作，也让我们对整个开发进度有了更清晰的把控。系统提示词：给AI立"规矩"的艺术如果把Claude Code比作一个新加入团队的开发人员，系统提示词（CLAUDE.md）就相当于给他的"入职手册"，告诉他团队的编码规范、工作流程和注意事项。新手常犯的错误： 把系统提示词写成"百科全书"，恨不得把所有项目知识都塞进去。结果AI要么忽略大部分内容，要么在生成代码时顾此失彼。我们早期的系统提示词长达5000字，包含了从架构设计到代码规范的所有内容，效果反而不好。实践心得：有效的系统提示词应该像"护栏"而非"详尽手册"。我们发现，针对AI常见错误模式设计的针对性提示，远比全面但泛泛的规范更有效。现在我们的系统提示词控制在200字以内，只包含最关键的约束和指引。系统提示词模板经过多次迭代，我们总结出包含三个关键模块的系统提示词结构：使用技巧分享几个在实践中总结的系统提示词编写技巧：避免信息过载： 不要试图包含所有知识，而是指引AI在需要时查询特定文档。例如："遇到分布式事务问题时，请参考/doc/分布式事务最佳实践.md文档中的TCC模式实现方案"。提供正向引导： 不仅说"不要做什么"，更要明确"应该怎么做"。例如，不说"不要使用过时的API"，而说"请使用OrderServiceV2替代OrderServiceV1。动态调整策略： 我们每两周会回顾一次系统提示词的有效性，根据AI最近常犯的错误补充新的约束。比如发现AI经常忘记处理空指针，就新增一条："所有方法入参必须进行非空校验，使用ValidateUtil.isEmpty()方法，异常时抛出IllegalArgumentException"。SKILL与MCP：知识沉淀与外部能力扩展在团队协作中，我们经常说"不要重复造轮子"。同样，在使用Claude Code时，我们也需要一种机制来沉淀和复用那些有效的Prompt和解决方案——这就是SKILL和MCP机制的价值所在。SKILL机制： 把好经验变成"可复用组件"SKILL本质上是将单次生效的Prompt指令沉淀为可反复调用的标准化复用资产。举个例子，我们团队处理"ES数据查询"逻辑时，总结出了一个内部版本的SDK。我们把这个SDK的调用方式封装成一个SKILL，以后遇到类似场景，只需调用这个SKILL，AI就能按照我们团队的最佳实践来实现。MCP协议： 让AI能"调用"外部工具MCP（模型上下文协议）解决了AI与外部工具、数据源的连接问题。通过MCP，AI不再局限于静态知识，而是能够动态访问实时数据。我们集成了飞书MCP服务器，让AI能够直接操作飞书平台，如自动生成技术方案文档、读取PRD需求、同步数据到多维表格等。最适合封装为SKILL的场景1.复杂工具使用指南： 如"ElasticSearch接入"、"Redis缓存更新策略"等需要特定知识的场景。2.常见错误处理模板： 如"分布式锁冲突处理"、"数据库乐观锁重试机制"等反复出现的问题解决方案。MCP协议的典型应用场景场景1: 自动生成技术方案文档AI分析需求后，通过飞书MCP调用feishu_create_doc；直接在指定的知识库目录创建格式化的技术方案文档；省去手动复制粘贴的繁琐步骤。场景2: 读取PRD需求用户提供飞书文档链接；AI通过feishu_get_doc_content获取文档内容；基于完整需求信息生成技术方案和实现计划。场景3: 数据同步到多维表格代码生成后的统计数据(如代码行数、涉及文件等)；通过feishu_append_bitable_data自动追加到飞书多维表格；便于团队追踪AI编程效率指标。三、对话流设计方法论：让AI"懂"你的真实需求刚接触Claude Code时，我们采用的是简单直接的"需求-响应"模式：开发者描述需求，AI生成代码，开发者修改调整。这种模式在处理简单功能时还行，但遇到复杂场景就会出问题。现状分析：传统对话模式的局限性我们早期在项目中踩过的三个坑：三大典型问题：需求表达不完整：开发者说"实现一个商家信息查询接口"，AI生成了基础的CRUD代码，但没有考虑商家数据权限、数据脱敏、缓存策略等实际业务需求 ；实现任务时，只描述了"需要任务分配功能"，结果AI生成的代码没有处理任务池、任务优先级、分配策略等核心逻辑。上下文管理混乱：一个对话持续了十几轮后，AI开始忘记我们前面确定的"使用MyBatis-Plus + BaseMapper"的设计决策，擅自改成了JPA Repository模式； 在实现相关功能时，早期确定的DTO转换规范在后续模块中被遗忘，导致代码风格不一致。迭代反馈滞后：等AI生成完整的Service + Controller + Repository代码后才发现方向不对，比如数据库表设计与现有架构冲突，不得不从头再来，浪费了大量时间；实现触达功能时，生成的飞书消息发送代码没有考虑现有的FeishuClient封装，重复造了轮子。核心问题：为什么AI总是"听不懂"？深入分析后，我们发现传统对话模式失败的根源在于三个核心矛盾：语义鸿沟自然语言描述的模糊性与代码逻辑的精确性之间的差距。我们说"这个接口要安全"，AI可能理解为"需要登录校验"，而我们实际想要的是：使用项目中的@Permission注解进行权限校验。参数需要使用ValidatorUtil进行校验。敏感操作需要记录操作日志。约束衰减随着对话推进，早期设定的技术约束在AI理解中的权重逐渐降低。就像我们记笔记时，重要的事情要反复强调。比如：第1轮对话强调"必须继承BaseServiceImpl"。第5轮对话AI可能忘记这个约束，直接实现了一个独立的Service类。第10轮对话可能连项目的分层架构都混淆了。目标偏移在多轮对话中，AI容易过度关注当前细节而忽视整体目标。比如讨论某个接口的参数设计时：AI可能会纠结于参数名称是否优雅。而忽略了这个接口的核心业务价值是"快速检索符合条件的商家"。结果生成的代码参数命名很完美，但缺少了分页、排序等实际必需的功能。解决方案：结构化对话设计方法针对这些问题，我们团队总结出一套"三阶段对话模型"，现在已经成为我们使用Claude Code的标准流程：阶段一：需求定义——把"要做什么"说清楚这个阶段的目标是确保我们和AI对需求达成共识。我们会用"用户故事+验收标准"的格式来描述需求：示例1：新商户成长任务分配【用户故事】 作为新商户运营，我需要一个任务分配功能，以便将成长任务高效分配给运营人员 【验收标准】 - 支持从任务池中按优先级(P0/P1/P2)筛选待分配任务 - 支持指定运营人员进行任务分配，需校验运营人员是否有权限 - 分配时需检查运营人员当前任务负载，超过上限时提示"当前任务数已达上限" - 分配成功后需发送飞书消息通知运营人员，消息内容包含任务详情和截止时间 - 操作需记录到表，包含操作人、操作时间、任务ID、分配对象示例2：商家数据权限查询【用户故事】 作为商家运营，我需要一个商家信息查询接口，查询结果需要根据我的数据权限进行过滤 【验收标准】 - 支持按商家ID、商家名称、商家状态进行查询 - 支持分页查询，默认每页20条，最大100条 - 查询结果需要根据当前用户的数据范围进行过滤 - 商家敏感信息(手机号、身份证号)需脱敏处理 - 接口需要权限校验，至少具有"商家查看"权限 - 查询条件需记录到操作日志，便于审计阶段二：边界明确——确定"怎么做"的约束条件在这个阶段，我们会明确技术栈选择、架构设计和各种约束条件。关键是要区分"必须遵守"和"建议参考"的约束：示例1：新商户成长任务模块【技术约束】 必须遵守: - 使用SpringBoot标准分层架构,所有Service继承OcsBaseServiceImpl - 数据库操作使用MyBatis-Plus,实体类继承BaseEntity,Mapper继承BaseMapper - 接口返回统一使用Result<T>格式,错误码使用ErrorCode - 权限校验使用@Permission注解,参数校验使用@Valid + ValidatorUtil - 飞书消息发送必须使用FeishuClient,不要重复实现 建议参考: - 任务状态流转参考TaskServiceImpl中的状态机模式 - 批量分配操作参考AssignImportHandler中的异步处理方式 - 运营人员权限校验参考OperatorRelationServiceImpl - 数据权限过滤参考ScopeServiceImpl中的范围查询逻辑 【数据库约束】 - 新增表必须包含created_at, updated_at, is_deleted字段 - 表名使用ocs_前缀,字段名使用蛇形命名法 - 索引设计需考虑查询场景,高频查询字段必须建立索引 - 外键约束通过代码层面维护,不在数据库层面创建示例2：机器人问答功能【技术约束】 必须遵守: - Controller层使用@RestController + @RequestMapping,路径遵循/api/v1/{module}/{action}格式 - Service层业务逻辑必须有事务控制,使用@Transactional(rollbackFor = Exception.class) - DTO转换使用项目中的ConvertUtil,不要手动赋值 - 第三方API调用(如Dify)必须有重试机制和降级策略 - 敏感配置(API Key)必须从配置中心读取,不要硬编码 建议参考: - 对话上下文管理参考RobotServiceImpl中的会话ID生成逻辑 - 消息发送失败重试参考FeishuMessageHandler中的重试策略 - 错误处理参考GlobalExceptionHandler中的统一异常处理 【集成约束】 - Dify API调用统一通过DifyClient,响应格式需转换为项目标准格式 - 飞书机器人回调处理需实现签名校验,参考FeishuEventHandler - 所有外部API调用需记录请求日志到integration_log表 阶段三：迭代反馈——在"做的过程"中持续对齐这个阶段的核心是增量验证，避免一次性生成大量代码后才发现方向错误。实践要点：1.分模块实现，逐个验证先实现核心接口(如任务分配)，验证通过后再实现辅助功能(如任务查询)。先实现Service层核心逻辑，验证业务流程正确后再补充Controller和参数校验。2.关键节点主动暂停数据库表设计完成后，先让开发者确认表结构再继续。核心业务逻辑实现完成后，先通过单元测试验证再生成Controller。集成第三方API前，先确认调用方式和参数映射。3.持续同步技术方案发现架构设计与现有代码不一致时，立即更新tech-solution.json和tech-solution.md。新增数据表、修改核心逻辑时，同步更新技术方案文档。每个模块完成后，更新模块状态为implemented → reviewed → verified。对话示例：开发者: "实现新商户成长任务分配功能" AI: "我将分三步实现: 1. 先设计数据库表结构(ocs_task_assignment表) 2. 实现核心分配逻辑(NewMerchantTaskAssignService) 3. 实现Controller层接口 现在开始第一步,设计的表结构如下: [展示表结构] 请确认表结构是否符合需求?" 开发者: "字段没问题,但索引需要加上(operator_id, status)" AI: "已更新索引设计,现在开始实现Service层核心逻辑... [生成Service代码] 核心逻辑已实现,包含: - 任务池查询(按优先级过滤) - 运营人员负载检查 - 任务分配和状态更新 - 飞书消息发送 请验证业务逻辑是否正确?" 开发者: "逻辑正确,继续实现Controller" AI: "开始实现Controller层... [生成Controller代码] 已完成模块M1实现,更新技术方案状态为implemented"对话设计三原则与常见问题应对策略为什么这样设计：背后的认知科学原理这种结构化对话设计不是凭空想出来的，而是基于我们对人类认知过程的理解：工作记忆限制理论： 就像我们一次只能记住7±2个信息块一样，AI的上下文理解能力也是有限的。通过分阶段对话和单次聚焦单模块，我们控制了每次交互的认知负荷。渐进式知识构建： 学习和理解是一个渐进过程，先掌握整体框架再深入细节，符合认知规律。这和我们教新人时"先讲架构图，再讲模块间交互，最后讲具体实现"的思路是一致的。四、AI团队协作模式：子代理系统的实践与思考随着团队使用Claude Code的深入，我们发现单个AI助手已经难以满足复杂项目的开发需求——就像一个人再厉害也干不了一个团队的活。于是，我们开始探索让多个AI"角色"协同工作的模式，这就是子代理（SubAgent）系统的由来。团队协作的现状与挑战在传统开发模式中，我们有需求分析师、架构师、开发工程师、测试工程师等不同角色，他们通过文档、会议和代码审查等方式协作。这种模式虽然成熟，但在快节奏的业务迭代中，我们发现了一些问题：协作中的三大痛点：信息传递损耗： 需求文档从产品经理到开发再到测试，每经过一个环节就可能产生一些理解偏差。就像玩"电话游戏"，信息传到最后可能已经面目全非。责任边界模糊： 当出现问题时，有时会出现"这是架构设计问题"、"这是实现问题"、"这是测试不充分"的互相推诿。反馈周期漫长： 从需求分析到代码审查，整个流程走下来往往需要几天时间，等发现问题时可能已经投入了大量开发资源。这些问题促使我们思考：能不能在Claude Code中模拟团队协作模式，让不同的AI角色各司其职又协同工作？Claude Code的子代理协作模式借鉴了MetaGPT等框架的思想，我们在Claude Code中构建了由多个专业化子代理组成的AI团队协作系统。每个子代理承担特定角色，通过标准化中间产物协同工作。核心工作机制：中间产物驱动所有子代理通过共享"技术方案文档"进行协作，这个文档就像团队的"共享白板"，包含需求分析、模块划分、实现状态和接口设计等关键信息。每个子代理只负责修改文档中与自己角色相关的部分，确保信息一致性。四个核心子代理角色技术方案架构师负责需求分析、技术方案设计和模块划分。相当于团队里的架构师，输出"技术方案文档"这个"施工蓝图"。核心职责：需求拆解与模块划分技术栈选型与架构设计接口定义与数据模型设计模块间依赖关系梳理技术方案文档编写与维护代码审查专家负责代码质量审查。扮演技术负责人的角色，从架构合规性、代码规范和稳定性等角度挑毛病。核心职责：检查代码是否符合架构设计验证代码规范和命名约定识别潜在性能问题和bug评估代码可维护性和扩展性提供具体修改建议代码实现专家专注于代码实现和单元测试编写。就像主力开发工程师，按照架构师设计的蓝图一块块地实现功能。核心职责：根据技术方案实现代码编写单元测试和集成测试修复代码审查中发现的问题编写API文档和使用说明同步更新技术方案实现状态前端页面生成器专门负责生成符合我们低代码平台规范的前端页面配置。这是针对我们商家域管理后台特点定制的角色。核心职责：根据接口定义生成前端页面配置实现表格、表单、详情页等标准组件配置页面权限和数据范围过滤优化前端交互体验确保符合设计规范和响应式要求协作流程我们采用"先整体规划，再迭代实现"的工作方式，有点像敏捷开发中的Sprint规划+Daily Scrum：1. 整体规划阶段：产品经理提供需求文档。协调者调用"技术方案架构师"子代理分析需求，生成技术方案文档。团队评审技术方案，提出修改意见。架构师子代理根据反馈修改方案，直到团队确认。2. 单模块迭代阶段：协调者从技术方案文档中选取一个模块。调用"代码实现专家"生成代码。调用"代码审查专家"审查代码。实现专家根据审查意见修改代码。重复"实现-审查-修改"直到通过。更新技术方案文档，标记该模块为"已完成"。进入下一个模块。子代理协作的价值与局限实践中的三个显著价值专业化分工提升质量： 每个子代理专注于特定领域，就像专科医院比综合医院在特定疾病上更专业一样。我们发现，专门的代码审查子代理比通用AI能发现更多潜在问题。流程标准化降低风险： 通过技术方案文档和明确的角色分工，开发流程被标准化和可视化。新人加入项目时，只要看技术方案文档就能快速了解整体情况。知识沉淀促进复用： 子代理的专业知识和决策逻辑被编码为可复用的配置和规则，避免了"人走经验丢"的问题。遇到的四个实际挑战子代理协作的挑战与应对：上下文同步问题： 当技术方案文档更新时，各子代理有时不能立即同步最新信息。解决办法：每次修改文档后，明确通知相关子代理"技术方案中XX部分已更新"。协作边界模糊： 在处理跨模块功能时，出现"该由哪个子代理负责"的困惑。解决办法：在技术方案文档中添加"责任人"字段，明确每个模块由哪个子代理负责。灵活性与标准化的平衡： 高度标准化的流程有时会限制处理特殊情况的灵活性。解决原则：90%的常规情况严格遵循标准流程，10%的特殊情况由人工介入处理。错误传递放大效应： 如果技术方案设计阶段就有问题，这个问题会在后续实现和审查阶段被放大。解决办法：加强技术方案的人工评审环节，确保"地基"打牢。子代理协作的设计思考在设计这套协作模式时，我们有几个关键思考：为什么选择"中间产物驱动"而非"直接沟通"？直接让子代理之间对话可能更灵活，但会导致沟通成本指数级增加（n个代理就有n(n-1)/2种沟通渠道）。通过"技术方案文档"这个单一事实来源，我们大大降低了协作复杂度，也便于追踪变更历史。角色划分的依据是什么？我们的角色划分基于软件开发的自然阶段（设计→实现→审查）和专业领域（后端→前端），这符合软件开发生命周期的自然规律。没有盲目追求角色数量，而是根据实际需求逐步增加。为什么采用"增量迭代"而非"一次性开发"？复杂系统的构建本质上是一个不断学习和调整的过程。增量迭代让我们能够及早发现问题并调整方向，避免在错误的道路上走得太远。这和我们常说的"小步快跑，快速迭代"理念一致。五、实践经验与未来展望经过几个月的Claude Code实践，从最初的"试试看"到现在成为离不开的开发工具，我们积累了一些经验，也对AI编程的未来有了更清晰的认识。实践经验总结人机协作的最佳平衡点：我们发现最有效的AI编程模式是"人类主导，AI辅助"，而不是反过来。我们将工作内容分为三类：AI主导： 标准化代码生成（如基础CRUD接口）、单元测试编写、API文档生成等重复性高、规则明确的任务。人机协作： 技术方案设计、复杂逻辑实现、代码审查等需要结合领域知识和创造性思维的任务。人类主导： 需求分析、架构设计、质量决策等高风险、高创造性的任务。上下文管理的实用技巧管理好对话上下文是用好Claude Code的关键，分享几个我们团队总结的技巧：对话线程化： 为不同功能模块创建独立对话线程。我们曾经在一个对话里讨论三个不同模块，结果上下文混乱到不得不从头开始。关键信息锚定： 重要的技术决策和约束要在对话中反复强调。就像写文章时，核心观点要多次出现。文档外化： 复杂设计和决策要记录在外部文档中，而不是仅依赖对话历史。我们会在对话中引用这些文档："数据库设计详见/doc/db_design.md，特别是索引设计部分"。状态可视化： 通过技术方案文档中的进度标记（如[未开始]、[设计中]、[已实现]、[已审查]），直观跟踪开发状态。质量控制的三个关键策略使用AI生成代码后，质量控制变得更加重要。我们的做法是：多层次验证： 单元测试（AI生成）+ 集成测试（人工设计）+ 代码审查（人机结合）的三层验证体系。渐进式信任： 从简单、低风险模块开始使用AI，建立信任后再逐步扩展。我们最先用AI生成内部工具，验证没问题后才用于核心业务系统。错误模式学习： 记录AI常犯的错误类型，针对性优化系统提示词。我们有一个"AI错误案例库"，记录了"AI忘记处理分布式锁超时"、"日期格式转换错误"等典型问题及解决方案。AI编程的局限性认知在实践过程中，我们也清醒地认识到AI编程并非万能解决方案，它有几个明显的局限性：创造性思维不足： AI擅长在已有知识范围内进行组合和优化，但在需要突破性创新的场景下表现有限。比如我们尝试让AI设计一个全新的商家结算模型时，它还是会倾向于参考现有模型进行修改，难以跳出固有思维框架。上下文理解深度有限： 尽管Claude Code的上下文窗口已经很大，但对于我们系统中某些"牵一发而动全身"的核心模块，AI还是难以把握其深层设计意图和与其他模块的隐性依赖。质量责任边界模糊： 当AI生成的代码出现质量问题时，责任界定变得复杂。我们的解决办法是：开发者对AI生成的代码负全部责任，就像我们对自己写的代码负责一样。领域知识滞后性： AI对我们公司内部系统的最新变更反应不够及时。为此我们建立了"知识库更新机制"，每月将最新的系统变更和业务规则整理成文档，供AI参考。未来发展方向思考基于这些实践经验，我们对AI编程工具的未来发展有几点思考：更智能的上下文管理： 未来的AI编程工具应该能自动识别相关上下文、追踪依赖关系，并在适当的时候提醒开发者潜在的上下文冲突。就像经验丰富的团队领导，能记住每个人负责的模块和项目的整体情况。多模态交互模式： 除了文本对话，未来可能引入图表、流程图等多种交互方式。有时画一个简单的流程图(PlantUML)，比写几百字描述更能说明问题。自适应学习机制： AI编程工具应该能从团队的使用反馈中学习，适应特定团队的编码风格和业务领域。就像新加入团队的开发者，会逐渐适应团队的工作方式。六、结语：人机协作的新型开发范式回顾这几个月使用Claude Code的经历，我们最大的体会是：AI编程工具的价值不在于替代开发者，而在于构建人机协作的新型开发范式。在这种范式下，人类开发者从繁琐的重复劳动中解放出来，更专注于需求分析、架构设计和质量把控等高价值创造性工作，而AI则承担起代码实现、文档生成和基础验证等标准化工作。Claude Code作为我们实践的核心工具，通过精准对话流设计、模块化任务分解和专业化子代理协作，展示了这种新型开发范式的潜力。但我们也认识到，成功的AI编程应用需要"工具+方法论+团队协作"三位一体的系统性变革，其中人的角色从"代码生产者"向"问题解决者"和"质量把控者"转变。作为开发者，我们需要保持开放学习的心态，积极探索和适应这种新范式。未来已来，与其恐惧被AI替代，不如学会与AI协作，在人机协作中实现更高的个人价值和团队效能。毕竟，代码只是解决问题的手段，而非目的；AI只是增强我们能力的工具，而真正的创新和价值，始终源于人的智慧和创造力。实践启示： 在AI编程时代，最有价值的开发者不是"写代码最快的人"，而是"最会引导AI、最能把控质量、最能解决复杂问题的人"。掌握与AI协作的技巧，建立系统化的AI辅助开发流程，将成为未来开发者的核心竞争力。我们的经验表明，通过合理设计对话流程、明确分工协作和严格质量控制，AI编程工具能够显著提升团队效能，但这需要整个团队在思维方式和工作流程上的共同转变。往期回顾1.入选AAAI-PerFM｜得物社区推荐之基于大语言模型的新颖性推荐算法2.Galaxy比数平台功能介绍及实现原理｜得物技术 3.得物App智能巡检技术的探索与实践4.深度实践：得物算法域全景可观测性从 0 到 1 的演进之路5.前端平台大仓应用稳定性治理之路｜得物技术文 /稚归关注得物技术，每周更新技术干货要是觉得文章对你有帮助的话，欢迎评论转发点赞～未经得物技术许可严禁转载，否则依法追究法律责任。
codex-session-clone 一个可以在切换供应商时把历史对话复制过去的小工具
简单来说就是最近在折腾 codex 反代，提升 codex 的使用体验，但是从 oauth 登录转到使用 api-key 时，发现以前的历史对话消失了，所以压榨研究出了这个小脚本 github.com GitHub - goodnightzsj/codex-session-cloner: 一个可以在切换供应商时把历史对话复制过去的小工具一个可以在切换供应商时把历史对话复制过去的小工具 一些小思考在现在的 vibe coding 时代，一些小需求真的可以很高效的解决了。这个问题从我产生解决这种需求的想法开始，到在论坛里搜索关键词没找到解决方案，再到我把 codex 仓库克隆下来丢给 antigravity 中的哈基米 3，第一次对话它就定位到了切换 provider 后历史对话消失的原因，后面告诉它用 py 脚本迁移之后就很快的给了我一个可用的版本，再丢给 chatgpt 网页版～～（codex 太慢了，小需求就没找它 debug）~~ 迭代了 2 次之后，整体用时不超过 20 分钟。而在传统古法编程的时代，要解决这个小需求，首先要读 codex 仓库定位问题，光是这一步消耗的时间起码就得在 30 分钟以上…… 对我这样的小菜鸡来说，这个时间更是得翻倍的。 哦，刚注意到 codex 代码基本是用 rust 写的，那花费时间为 0。在我花时间学会 rust 之前，我是看不大懂 rust 代码的，所以我只能等某个大手子出手才能直接无脑使用。但为了这个很小的需求，我是不大可能去学 rust 的，有这时间去玩会不香吗？我会自适应历史对话消失的小问题，又不是不能用📌 转载信息来源： https://linux.do/t/topic/1507194原作者： hello_world1024转载时间： 2026/1/24 06:44:31
这两天跟朋友吃饭，又聊到了AI。即使到现在，依然有很多人坚持一个观点：AI永远不可能取代程序员，它只是一个提高效率的辅助工具。他们觉得，有了AI，程序员会变得更强，而不是消失。说实话，这种想法太乐观了，甚至可以说是在自我麻痹。我直接抛出我的结论：AI不仅会淘汰程序员，而且这个过程已经开始了。特别是对于初级和中级程序员来说，倒计时已经响了。咱们别整那些虚头巴脑的比喻，什么“工具论”、什么“驾驶员论”，咱们就实打实地看看现在发生了什么。第一，我们的工作方式彻底变了。回想一下两年前你怎么写代码？遇到不会的API，或者想不起来的语法，你会去谷歌，去百度，去Stack Overflow，去CSDN或者掘金。你会翻看别人的博客，找到解决方案，理解它，然后应用到你的代码里。现在呢？大部分时候，你只需要在IDE里敲一行注释，AI就给你补全了后面的代码。或者你直接把报错信息丢给AI，它直接给你修复后的代码。你甚至都不需要离开编辑器。这个过程省去了什么？省去了“搜索、筛选、理解、尝试”的过程。你直接得到了结果。第二，技术社区正在走向消亡。这是一个很可怕的连锁反应。因为大家都有了AI，遇到问题不再需要去搜索引擎搜了，也不需要去论坛问了。这就导致了技术博客和问答社区的流量断崖式下跌。没人搜，就没人看；没人看，就没人写。原来的技术分享生态是基于“互助”和“展示”的，现在AI把这个需求截断了。以后新的坑、新的Bug解决方案，可能再也不会出现在公开的网络上了，因为AI在它内部的数据库里就已经消化解决了。第三，也是最关键的，需求方变了。以前开发软件，流程是：产品经理 -> 需求文档 -> 程序员理解 -> 编写代码 -> 测试。现在有了像Trae这样的智能IDE，或者是各种Agent（智能体），流程正在变成：人提出需求 -> AI理解需求 -> AI生成代码 -> AI自我修正 -> 人最后确认。注意到了吗？“编写代码”这个环节，正在从人的手里，转移到AI的手里。现在的AI工具，已经不仅仅是补全一行代码那么简单了。你告诉它你要做一个什么样的功能模块，它能直接给你生成整个文件，甚至帮你把相关联的配置文件都改好。以前你需要写几百行代码来实现一个逻辑，现在你只需要用自然语言描述清楚你的逻辑。这就带来了一个残酷的数学题。如果以前一个项目需要5个初级程序员写业务代码，1个高级程序员做架构。现在有了AI，那个高级程序员配合AI，一个人就能把那5个人的活儿干完，甚至干得更快、Bug更少。那剩下的5个人去哪儿？公司是为了赚钱的，不是慈善机构。当效率提升了5倍，老板不会雇佣原来的6个人去干5倍的活，而是会裁掉那5个人，只留1个成本最低、效率最高的人。写在最后所以，别再觉得AI只是个工具了。当一个工具强导致能独立完成大部分工作时，它就成了劳动力本身。未来的软件开发，可能真的不需要那么多“写代码”的人了。我们需要的是能精准描述需求的人，是能设计复杂逻辑的人，是能判断AI生成结果对错的人。纯粹的“代码编写者”，正在消失。这不是焦虑，这是正在发生的现实。
我这种情况，当下有没有必要入手一个 Mac，求拔草或种草
个人情况： Java 、Python 、go 、前端都写过 从未用过 Mac ，家里有台式机作为主力开发，还有 NAS 和轻薄本 Windows ，偶尔外出用笔记本远程家里台式 Windows 下个人开发遇到的问题 AI 总是优先使用 bash 语法，vibe coding 是经常先运行 bash 命令，看到报错再切换成 powershell ，即使增加全局 prompt 告诉它这是 windows 有时还是会失效，写的 powershell 也经常失败 很多 AI 工具对 unix 的支持比 windows 好得多，像 claude code 。一些前沿工具如 bun 也是最近才有 Windows ，而且据说还不完善 使用 wsl2 折腾过，jetbrains 系有些不能很好适配。而且如果代码在 wsl 中，jetbrains 和 vscode 系的相互跳转插件就失效了 如果新增 Mac 作为主力开发工具 考虑鱼上收一个 Mac mini 16+256 ，我有 NAS 可以开 docker ，不太需要内存和存储，也没有跑大模型的需要 有远程需要就用笔记本远程 Mac 主要是想 vibe coding 体验更好些，因为我没用过 mac ，想看看大家的意见
模型角度 T0: claude 默认的、gemini 、chatgpt5.2 国产模型大差不大 在逻辑实现和技术方案制定上，感觉国外的这 3 个更符合我的审美。。。agent白嫖了同学的 claude code ，token 管够的情况下很爽。代码接受率很高，业务屎山也改得动，给的技术方案可落地性也很强。应该是用的国内中转的，速度稍慢。后面换了 glm code plan ，差距挺大的，只能日常处理点简单编码逻辑，尤其在提示词和代码的理解上和原生 claude 差距巨大。需要给特别明确的 prompt 才能做好。windsurf 出了 idea 的插件，自带的 swe1.5 ，感觉水平不比国产的差，速度极快，体验还不错。但是自动补全经常出不来。直接用 windsurf ide 体验更好。trae 整体可用，但用多了排队很烦。JB 家在 AI 时代整体落后了，插件的体验和原生 ide 差距还是有的。不过原生 ai ide 越强，更能体现 JB 在没 AI 时代的强大。windsurf ide 也能写 java ，ai 的配套已经挺强大了，但整个 java+spring 的编码配套还是不如 idea 的。
国产口粮模型选择，请投出你的一票
之前的帖子 这可能是下一个周经帖：国产大模型哪个编程能力最顶？已经过去一段时间，现在不少模型都已经更新了，而且都支持方便的接入 claude code 等 cli 工具或者 cursor 这样的 ide 。那么，在众多的国产模型中，从你的实际体验出发，哪个国产模型才是最佳日常编码的口粮模型呢？量大管饱，能处理大多数场景的需求。来吧，分享一下你的体验！GLM-4.7:目前收集到的信息是，测试的时候效果还不错，能跟 sonet 4.0 有来有回，coding plan 也比较便宜，但是超售严重，订阅后降智严重MiniMax M2.1:也推出了自己的 coding plan ，总的来说反馈还是不错DeepSeek-V3.2：写代码还是不太行，听说 4.0 很强！kimi-for-coding：听说比较蠢，具体请反馈Doubao-Seed-Code：最近新出，还得到了阮一峰推荐 https://www.ruanyifeng.com/blog/2025/11/doubao-seed-code.html
【超详细经验贴】我用这个流程白嫖 5 年 Copilot（Microsoft365），爽用 GPT-5.2！！
继 elsa 佬的免费白嫖 2-5 年 Copilot（Microsoft365），可用 GPT-5.2 - 福利羊毛 / 福利羊毛，Lv1 - LINUX DO 分享一下个人的踩坑流程一、准备材料：1.1 教育邮箱：我用的教育邮箱是美国社区大学.edu（以前薅 cursor 的邮箱留存至今）没有邮箱的佬可以看一下 Mirage 佬的：关于 “免费白嫖 2-5 年 Copilot” 如何获取 edu 邮箱！ - 福利羊毛 / 福利羊毛，Lv1 - LINUX DO关于如何成为美国大学生（bushi）申请 EDU 邮箱的教程 - 福利羊毛 / 福利羊毛，Lv1 - LINUX DO1.2 新申请的 Microsoft 账号 + 美国节点 +Chrome+GoolePay（我绑的是 ypt）ps：我用香港节点 + 支付宝验证后都是 2 年的二、验证流程：2.1 申请一年的个人版（点我直达）：（申请顺序不能变）(https://checkout.microsoft365.com/acquire/purchase?language=zh-us&market=US&requestedDuration=Month&scenario=microsoft-365-student&client=poc&campaign=StudentFree12M) ps: 我的用的是美国节点，链接里是 us（没有改 tw or hk）2.1.1 添加支付方式 GoolePay + 教育邮箱验证 >> 教育邮箱验证链接获取可能得报错（直接重新刷新个人版申请链接即可）2.1.2 添加地址（ai 生成的，地址好像不重要）2.1.3 开始支付 >> 个人版申请成功2.2 申请一月的高级版（点我直达）：（申请顺序不能变） https://checkout.microsoft365.com/acquire/purchase?language=zh-TW&market=US&requestedDuration=Month&scenario=microsoft-365-premium&client=poc&campaign=StudentPremiumFree12M 2.2.1 接着个人版申请（会显示个人版的到期时间）可能得报错（try again 多来几次即可）2.2.2 添加 Goole Pay>> 开始支付可能得报错（持续刷新几次即可）2.2.3 高级版验证成功三、关闭自动续订3.1 点击管理订阅3.2 关闭自动续订以上纯为个人的验证流程，大佬勿喷，请指正！！📌 转载信息来源： https://linux.do/t/topic/1487019原作者： muzhiyang转载时间： 2026/1/20 10:35:21
Agent 不是渐进升级，而是要“换代”了：Cursor 工程负责人放话未来三到六个月，行业将迎来大变局
整理 | 华卫、Tina过去一年，编码 Agent 的变化速度，已经快到让人很难用“功能升级”来形容。如果把时间拨回到一年前，Agent 还主要停留在代码补全、对话式改几行代码的阶段；而今天，在 Cursor 内部，工程师已经开始同时运行多个 Agent 并行“甩活儿”，让它们在代码库中自主修改、调试、复盘，再由人类在最后阶段集中审核结果。开发者不再盯着 Agent 的每一步操作，而是开始习惯“等它跑完再看答案”。在最近一次访谈中，Cursor 工程负责人 Jason Ginsberg 给出了一个明确判断：这不是渐进式优化，而是一场正在发生的“换代”。更重要的是，他把这场变化的时间窗口，压缩到了未来三到六个月——在他看来，Agent 将不只是“更聪明”，而是会真正接管更长周期、更复杂的工程任务，整个行业的工作方式也将随之重塑。下面是详细对话内容，我们在不改变原意的基础上进行了翻译和删减，以飨读者。一年多时间，编码 Agent“翻天覆地”Harrison Chase：Jason，你能跟大家简单介绍一下自己吗？也给大家讲讲 Cursor 是什么吧。 Jason Ginsberg：好的。我目前在做一款 AI 编程工具，已经在 Cursor 工作了六个月，担任该产品的工程负责人。不过说实话，我日常的大部分时间还是在写代码和做设计工作。在加入 Cursor 之前，我在 Notion 负责 Notion Mail 相关工作。几年前，我创办了一家名为 Skiff 的公司，后来这家公司被 Notion 收购了。所以，我一直都在从事产品开发相关的工作，而且主要聚焦在生产力工具领域。 Harrison Chase：非常棒。我有很多话题想和你探讨。要不我先抛砖引玉，问问你对编码 Agent 的发展历程，以及这些年来人机交互模式演变的看法吧。你们可以说是这个领域的先行者之一，我认为编码 Agent 的发展经历了几个阶段的转变：从最初的代码自动补全，到集成在集成开发环境（IDE）中的对话式交互，再到如今出现的各类终端工具，以及基于云端的异步 Agent。我很想听听你的看法，你觉得这样概括其用户体验的演变历程是否准确？或者你们团队是如何看待这一发展过程的？ Jason Ginsberg：我认为编码 Agent 的发展确实可以用 “翻天覆地” 来形容，而且这些变革基本上都是在一年多一点的时间里发生的。正如你所说，Cursor 最早开启了代码自动补全的先河，这种模式主要是在逐行的层面上提供辅助，适用范围也基本局限在单个文件内。而此后，几乎每隔几个月，我们就不得不提升产品的抽象层级，这其实是一个极具挑战性的产品设计难题。显然，Agent 的出现让开发者能够在多个文件之间灵活切换，并且可以放心地让 Agent 自主完成代码修改工作。 在过去两个月左右的时间里，我发现行业又出现了新的转变：开发者现在已经能够做到从项目启动到结束全程信任 Agent，并且会对整个代码库中多个文件的内容进行批量审核。因此，我们不得不对产品的整体布局进行大幅重新设计，将核心从逐行的代码差异对比，转向更偏向代码审查的模式。 展望未来的产品开发方向，我们的工作重心其实会更多地放在多 Agent 协同运行上。我们需要实现的是，能够快速验证这些 Agent 是否在正常运行，并且可以让它们并行工作，同时避免受到当前单一对话模式下各种选项和选择的束缚。 Harrison Chase：推动这些变革的核心因素是什么？仅仅是因为大模型的性能变得越来越好，还是有其他更多的影响因素？ Jason Ginsberg：我认为大模型性能的提升是一个很关键的因素，这让开发者能够更加信任 Agent 编写的代码质量。要知道，以前大家必须对 Agent 生成的代码进行非常全面细致的审查。同时，现在也有了更完善的代码审查工具。比如我们有 BugBot，市场上其实还有很多类似的工具，它们都能够自动检查代码中存在的问题。 此外，我觉得从行业文化层面来看，开发者们对 Agent 工具的接受度和使用信心也在不断增强，甚至可以说已经 “上瘾” 于这类工具带来的便捷。而且，一旦习惯了完全依赖 Agent 进行编码的工作模式，再切换回传统的编码方式其实是很困难的。所以现在，我们能看到越来越多的开发者已经将 Agent 辅助编程作为默认的工作方式。最顶尖工程师的干活秘诀：全靠 Agent？Harrison Chase：你观察到大家使用 Cursor 的方式都有哪些不同？或者你自己平时是怎么使用 Cursor 的？ Jason Ginsberg：其实在我们公司内部，工程师们使用 Cursor 的方式就五花八门。甚至团队里有几位工程师，他们完全不使用 Cursor 的 Agent 功能，比如负责安全和基础设施的同事。所以，确实有一部分用户非常依赖代码自动补全功能，日常使用中大部分操作都是基于补全功能完成的。但令人意外的是，我发现团队里一些最顶尖的工程师，我们称他们为 “核心用户”，他们做任何工作都会完全依赖 Agent，甚至会同时运行多个 Agent 并行处理任务。 至于我个人的使用习惯，我并不会去设计那些复杂繁琐的提示词，也没有什么所谓的 “Agent 使用秘籍”。我写的提示词往往都很简短，甚至还会带有拼写错误。我会针对手头不同的工作任务，或者同一个问题的不同模块，同时启动多个 Agent，然后等待它们返回结果。 目前我用得最多的是我们今天刚刚发布的一个新功能：调试模式。这个模式下，Agent 能够通过生成日志来进行自我评估，之后开发者复现相关操作步骤，Agent 就会通过查看日志判断问题是否得到解决。这个功能非常实用，因为它相当于通过投入算力去不断尝试解决问题，最终攻克那些手动排查起来极为棘手的难题。 Harrison Chase：调试模式具体是什么样的？为什么需要专门设置这样一个模式？难道不能自动完成调试吗？直接给 Agent 下达调试指令不也可以吗？ Jason Ginsberg：其实我也认同你的这个想法。所以在开发调试模式的时候，我们内部确实有过不少争论。主要原因在于，Cursor 目前已经有很多功能模式了，如规划模式、询问模式等等，这些模式其实不太容易被用户发现。我们一直认为，这些模式都很实用，理想的状态应该是，Agent 能够根据用户的操作场景，自动匹配并启用最合适的模式，无需用户手动切换。 而现阶段调试模式之所以需要手动开启，是因为它的交互方式比较特殊。在运行过程中，Agent 会暂停当前的工作，向用户提问以获取反馈。如果用户不熟悉这种交互逻辑，可能会觉得比较困扰。 Harrison Chase：Agent 具体会询问哪些问题，又需要用户提供什么样的反馈呢？ Jason Ginsberg：我举个例子吧。假设我正在开发一个前端应用，遇到了一个很让人头疼的问题：菜单总是在左上角弹出。这时候我会对Agent说：“这个菜单需要锚定到按钮的位置。” 随后，Agent 会启动服务器，并在整个代码库中添加大量日志，同时提出一系列可能导致该问题的假设，如 “可能是某个定位参数设置错误”、“可能是事件绑定逻辑有问题” 等。之后，Agent 会提示我：“麻烦你点击这个按钮，打开菜单，看看问题是否解决。” 如果我反馈问题依然存在，Agent 就会查看生成的日志，然后分析判断：“这个假设成立，那两个假设不成立”。通常这样反复两三次之后，Agent 往往就能找出并解决问题。 Harrison Chase：你觉得人类还需要手动操作多久？就不能让 Agent 自主完成点击、测试这类操作吗？ Jason Ginsberg：一两个月内，毕竟这个行业的发展速度实在太快了。 Harrison Chase：刚才你提到了 Agent 的多种不同模式，比如规划模式、解释模式、调试模式等等。这些模式在实际应用中到底意味着什么？难道只是为 Agent 设置不同的提示词这么简单吗？还是说背后有更复杂的逻辑？ Jason Ginsberg：很多时候，确实就是修改一下系统层面的提示词。不过在某些情况下，我们也需要对用户界面进行相应的调整。比如规划模式现在也加入了交互提问功能，运行过程中会主动打断用户操作，寻求反馈。用户有时也可以自行设置参数，如调整 Agent 打断的频率等。再比如询问模式，它不只是依赖特定的系统提示词，还会限制 Agent 调用某些与文件编辑相关的工具，以此来保证功能的稳定性和可靠性。 Harrison Chase：回到之前的话题，关于大家使用 Cursor 的不同方式，你觉得未来使用编码 Agent 或者说 Cursor，存在所谓的 “最佳方式” 吗？ Jason Ginsberg：我觉得并没有什么 “最佳方式”，具体的使用方法很大程度上取决于工程师的个人工作习惯以及他们所处理的具体工作内容。目前行业里，既有异步运行Agent的应用场景，也有开发者深度参与、实时交互的模式，就像一边编程、一边像画画一样实时调整代码或者进行可视化的编辑操作。不过我经常在推特上看到一些所谓的 “Agent 使用技巧”，其实对此我是有点持保留态度的。很多人会说 “这才是使用 Agent 的最佳方式”，但在我看来，这些技巧往往是凭空杜撰的。 我们团队内部其实并不会使用那些冗长复杂的提示词，也不会采用多阶段规划的策略。大多数时候，我们都是快速迭代，如果 Agent 运行的结果不理想，就直接终止进程，重新启动 Agent。通常这种方式的效率是最高的。自然 “唠嗑”是 Cursor 最终交互模式？Harrison Chase：如果让你预测一下一年后的情况，你认为开发者在 IDE、终端以及其他形态的载体上使用 Cursor 的时间占比会是怎样的？ Jason Ginsberg：当然，我肯定会带有一定的主观偏向性。但我认为，终端工具并不会成为用户的首选。我觉得，真正驱动行业发展的是用户对Agent的信任度不断提升，他们更希望等到Agent完成所有工作后再查看最终的修改结果，然后决定是否采纳，同时也愿意让 Agent 运行更长的时间，以实现更智能的处理。 而 IDE 之所以至关重要，是因为它是为整个软件开发周期量身打造的工具。从项目的构思规划，到运行代码修改、查看代码内容、清晰对比代码差异、提交代码合并请求，再到在浏览器中预览效果所有这些环节，都可以无缝集成在 IDE 的模块化功能之中。这一点其实很容易被忽视，毕竟 IDE 的这些功能是经过了数十年的发展才逐步完善起来的。 我认为，当前行业的一个明显趋势是，产品层面的设计变得越来越重要。现在 Cursor 用户使用频率最高的功能，如规划模式，其实都需要可视化编辑器的支持，用户需要能够在编辑器中添加注释，并进行实时交互。一旦脱离了按钮、弹窗和菜单这些可视化交互元素，用户与工具的交互难度会大大增加。 不过，我觉得未来并非所有操作都必须局限在笔记本电脑的 IDE 中完成。这种模式并不会被完全取代，具体的使用场景会根据实际需求灵活变化，适用的场景也会更加广泛。用户在更多场景下，都能够使用到 Cursor 这样的工具。 Harrison Chase：未来会有更多场景都能用上像 Cursor 这样的工具。你们应该有对应的官网吧？用户可以直接在网页上进行交互操作，是这个思路吗？ Jason Ginsberg：对，我们确实有官网。这么做的原因是用户可以通过手机等设备随时随地访问。我觉得在不远的将来，用户完全可以戴着 AirPods，开启语音模式，和Agent实时沟通、碰撞想法，让Agent不断优化方案。等用户到了办公室，打开笔记本电脑，就已经有一堆代码修改记录或者演示视频等着审核了，到时候只需要简单确认通过或者驳回就行。如果某些细节还需要微调，再把项目下载到本地修改就好。 Harrison Chase：我认为 Cursor 真正的优势，在于围绕 Agent 交互打造的整套设计和用户体验体系。你之前在 Notion 工作过，我记得即便是在生成式 AI 普及之前，Notion 的设计和用户体验就已经广受认可了。当然，他们在生成式 AI 时代也很好地完成了转型。从一家在生成式 AI 普及前就拥有出色设计积淀且顺利完成转型的公司，再到如今专注 Agent 相关工作，你觉得 Agent 的出现给产品设计和用户体验带来了哪些变化？现在的工作模式和之前有相似之处吗？ Jason Ginsberg：我觉得总体来说，我们产品的大部分设计其实并不是 AI 专属的。要知道，产品可用的交互组件和用户体验模式就那么多，市面上的应用本质上也都是基于一些传统的模式搭建的，如收件箱、仪表盘、聊天界面，这些都是很成熟的设计。所以我们的工作核心，更多是把这些现有的设计模式进行合理组合，然后在产品中恰当地呈现出来。这一点和 Notion 的产品理念是相通的，同时也是 Cursor 和集成开发环境（IDE）的核心特质：极高的模块化程度。 作为用户，你会发现每个人的 IDE 界面布局都可以千差万别。你可以自定义面板布局，把任意组件拖放到任意位置，和坐在你旁边的同事设置出完全不同的界面。我认为这种模块化设计对产品的适应性至关重要，毕竟如我之前所说，Agent 的能力发展日新月异，用户对产品的需求和期待几乎每隔几周就会发生变化。几个月前我们推出 Cursor 2.0 的时候，并没有把原来的产品推倒重来，只是把各个功能模块重新组合，调整为侧边栏收件箱式的管理布局，同时优化了聊天界面的信息密度而已。 Harrison Chase：听你这么说，很多组件的底层逻辑其实是相通的。那有没有出现新的组件？或者某些组件的优先级发生了变化？毕竟这些组件最初都是为 “人类与软件交互”“人类通过软件协作” 的场景设计的，现在加入了 Agent 这个新角色。这其中有没有产生什么新的变化？还是说其实本质上没有太大不同？ Jason Ginsberg：我认为底层的设计逻辑和核心要素其实没有变，关键变化在于谁在主导界面交互。而在这个核心框架下，其实可以演变出无数种交互形式。就拿交互的抽象层级来说，一年前大家使用Agent的时候，都恨不得盯着它的每一步操作，全程 “盯梢”。但现在 Agent 的操作步骤变得无比繁杂，用户根本看不过来。所以我们需要优化信息呈现方式：如何对操作步骤进行分组？如何提炼关键信息？ 当用户足够信任 Agent 的操作后，我们就需要把重点放在文件的实际修改内容上，并且为这些修改添加更详细的注释说明。当然，我们也可以进一步提升交互的灵活度，比如聊天对象不再局限于单个 Agent，而是可以同时和多个 Agent 对话。这就需要一套更智能的后台交互逻辑来支撑 ，系统要能识别用户在和哪个子 Agent 对话，并且协调这些 Agent 完成对应的修改。未来这种交互的抽象层级还会不断提升。 Harrison Chase：你觉得交互的抽象层级最高能达到什么程度？我知道预测未来很难，但还是想听听你的看法。 Jason Ginsberg：我觉得未来，我们现在看到的各种操作选项，如选择模型、选择功能模式、选择运行环境这些都会逐渐消失。最终的交互模式会变得像和真人对话一样自然。但这并不意味着任何人都能随便写代码，在那个阶段，这个工具依然是为专业工程师服务的。因为你还是需要具备专业的行业术语知识，清楚自己想要修改的内容是什么。做产品的人，要明确自己想要的工作流程和功能需求；做基础设施的人，要足够了解代码库，知道什么样的架构和系统设计最适合当前要开发的项目。 而且我想强调的是，随着抽象层级的提升，我们并不会摒弃现有的功能。用户依然可以随时深入底层，查看细节、调整参数。只是产品的默认交互方式会不断优化升级。Cursor 内部工作揭秘：少审代码、高频反馈Harrison Chase：你之前提到了人类在 Agent 工作流程中的角色，比如查看代码差异、进行代码审查。你觉得 AI 会给代码审查工作带来哪些改变？ Jason Ginsberg：首先，就我们产品团队的工作模式来说，现在人工审查的比重已经大幅降低了。我们有一个叫 BugBot 的工具，它会自动检测代码问题，并且自主完成修复，还会在持续集成（CI）流程中不断迭代优化。这个工具的表现非常出色，也让我们对 AI 审查的代码质量更有信心。 其次是信息的语义化分组。用户查看代码差异时，可以清晰地看到 Agent 做了哪些修改。我们甚至可以展示 Agent 的原始指令，更理想的状态是，Agent 能够像人类一样，在处理大型代码合并请求时，为每一处修改附上注释，说明这么做的原因。我觉得这虽然算不上颠覆性的变革，但确实能给代码审查工作带来显著的优化。 Harrison Chase：出于好奇，我想问一下，Cursor 的工程师用 Cursor 写代码，用 BugBot 审查代码，那他们还需要和其他工程师沟通协作吗？ Jason Ginsberg：哈哈，这个问题很有意思。如果你以工程师的身份加入 Cursor，会立刻发现一个现象：所有人都在深度使用自家产品。我记得我入职第一周的时候，修改了一个快捷键设置。那个快捷键是 Alt+Shift+Command+J，非常冷门，我当时觉得选这个键肯定没人会注意到。结果刚改完不到半分钟，就有三个同事在 Slack 上发来消息：“你改的这个快捷键直接打乱了我的工作流程！到底怎么回事？”几乎任何产品改动，都会立刻收到同事们的强烈反馈。我觉得这其实是一件好事，大家就是在这种高频的反馈和交流中，快速推进产品迭代的。 Harrison Chase：从组织管理的角度，你们有没有采取什么措施来鼓励或者引导这种高频反馈的协作模式？毕竟大量的反馈涌进来，有时候也会让人应接不暇。 Jason Ginsberg：在我创办自己的公司之前，工程师们也会用邮件沟通，但用得并不多。大家甚至会说：“邮件只用来收垃圾邮件和购物通知，可别用它来发长篇大论的工作内容。”而在Agent这个赛道工作，其实完全不需要依赖邮件这种低效的沟通方式。我们团队的所有人都全身心投入工作，毕竟这是一个竞争非常激烈的领域，大家都对产品开发充满热情，会自然而然地用各种即时沟通工具协作。 另外，我在规划产品功能时，会遵循一个核心原则：我能开发什么功能，让自己的日常工作更轻松？ 具体来说，就是思考 “做什么能帮我明天更高效地完成工作，不用再处理那些烦人的报错和问题”。这个原则指导着我们的大部分工作。毕竟这种功能开发出来之后，我们自己能立刻受益，比如修复了一个烦人的漏洞，以后上班就不用再被这个问题困扰了。迭代狂飙背后，核心功能竟来自员工 “自嗨”？Harrison Chase：你觉得你们的产品路线图，有多大比例是由 “让自己工作更轻松” 这个需求驱动的？又有多大比例是来自外部用户的需求？这个比例随着公司发展有变化吗？ Jason Ginsberg：这个比例确实随着公司规模的扩大在变化。现在我们也会制定月度的产品路线图和目标，但说实话，我们很多核心功能都来自自下而上的创新。比如 Cursor 的Agent功能，这可以说是大家提到 Cursor 时最先想到的核心功能。这个功能是我们团队的一个人开发的，最开始所有人都不看好这个想法，但他很快做出了原型。大家试用之后都惊叹：“哇，这东西居然真的能用！” 我之前提到的调试模式也是如此。感恩节假期的时候我闲着没事，就开发了这个自己很需要的功能，现在这个功能也即将上线。这些功能的开发初衷，都是为了解决团队内部的需求。我们判断一个功能是否具备发布条件，一个重要的衡量标准就是内部的使用率和认可度。 Harrison Chase：你们的产品迭代速度快得惊人，是怎么保持这种高效的开发节奏的？ Jason Ginsberg：说实话，我们的工作流程其实非常精简，没有太多繁琐的制度。公司里虽然有几间会议室，也有一两位产品经理，但我们很少通过撰写文档或者开对齐会议来推进工作，大部分的讨论和决策都是在代码层面完成的。而这一切能够实现的核心原因，是我们对人才的极高要求。今年年初的时候，公司总共也就 20 人左右。之所以团队规模增长缓慢，就是因为我们的招聘门槛高到近乎苛刻。我们会反复评估：这个人很优秀，但他能成为团队里最顶尖的那批人吗？ 正因为团队里的每个人都足够出色，所以我们可以放心地把任务交给任何一个人。团队成员的主观能动性都极强，从提出想法、设计用户体验，到在推特上回复用户的支持请求、和企业客户沟通需求，再到最终将功能落地，整个流程都能独立完成。所以说，我们能保持这样的速度，归根结底还是人的因素。 Harrison Chase：你们是如何规划产品路线图的？你刚才提到了以月为单位的规划周期，这是目前的常规规划时长吗？有没有更长期的规划？另外，行业技术迭代的速度实在太快了，你们是如何平衡 “跟进现有技术浪潮” 和 “实现技术跨越式发展” 这两者的？会不会主动预判技术趋势，提前布局未来方向？ Jason Ginsberg：我们确实会投入不少精力去思考未来，比如预判未来三个月可能实现的技术突破，然后主动押注相关方向，团队里有相当一部分人都在做这类前瞻性的工作。我们制定的月度路线图更多是围绕核心产品功能展开，聚焦于用户的实际需求以及那些能优化日常使用体验的功能。而那些需要投入两个月时间重构底层逻辑的重大项目，则会纳入更长期的规划范畴。此外，我们的应变能力其实非常强。 有时候我们会提前拿到新模型的测试版本，试用之后如果发现它在某些方面表现特别出色，团队成员往往会主动利用周末时间加班，争取在新模型正式发布前就完成相关功能的开发。很多重要功能其实几天之内就能搭建完成。 Harrison Chase：说到模型，你们发布了自研的 Composer 模型。开发这个模型的初衷是什么？目前用户的使用情况如何？这个模型有没有改变大家使用 Cursor 的习惯？ Jason Ginsberg：我们发现，工程师使用我们产品时的编码场景，需要有专门适配的模型来支撑。Composer 模型就是针对这类场景打造的，它定位非常明确，具备速度快、质量高、逻辑智能三大特点，尤其适合 “人机实时协作” 场景。我自己做前端开发时就经常用它，因为我需要频繁做出细微的交互设计决策，这就要求 Agent 能在几秒内给出反馈。Composer 就像一个高效的协作伙伴，能快速响应需求、碰撞想法，和那些适用于长周期异步任务的模型形成了很好的互补。 Harrison Chase：Cursor 的 Agent 相关研发工作是全员参与，还是有专门的团队负责？ Jason Ginsberg：我们确实有专门的团队负责 Agent 的性能优化，他们主要聚焦于工具链、调度框架的搭建以及效果评估。但正如我之前所说，我们的团队架构并不僵化，没有严格限制大家的工作范围。比如核心产品团队的工程师在开发规划模式时，如果需要对Agent进行调整，就会和Agent团队密切协作。而且在开发过程中，我们依然会深度使用自家产品进行测试，团队成员会分享使用感受，以此来评估功能的实际效果。 Harrison Chase：无论是 Agent 团队的成员，还是其他团队中擅长 Agent 研发的工程师，他们身上有没有什么共同特质？他们的专业背景或者个人能力有没有什么特别之处？ Jason Ginsberg：我觉得他们大多是偏产品方向的人才，而不是传统意义上的机器学习或算法研究专家。这些人经常在不同团队之间轮岗，因为Agent研发需要对用户的最终使用体验有很强的直觉，同时还要能准确解读团队的反馈意见。 Harrison Chase：上周你们和 OpenAI 合作发布了一篇博客，内容是针对 OpenAI 的新模型优化 Cursor 的 Agent 调度框架。我在推特上经常看到大家讨论 “Agent 调度框架” 这个概念。你们是如何看待模型的底层支撑架构的？这类架构是否需要和特定模型深度绑定？比如 Composer 模型和 CodeLlama 模型，对应的架构会不会有很大差异？ Jason Ginsberg：我其实没有深度参与这方面的工作，但据我了解，我们的核心目标是打造高度灵活的架构。毕竟我们需要不断尝试新技术、新功能模式，所以架构必须能够随着模型能力的升级快速适配。 Harrison Chase：很有道理。毕竟整个行业都在飞速变化。开放问答提问者 1：刚才提到了新增的可视化浏览器功能，我发现有些工具比如 Lovable 也有类似的功能。请问这个功能是朝着 “沉浸式可视化编码” 的方向发展吗？ Jason Ginsberg：我觉得它并不是为沉浸式可视化编码设计的。就像我之前说的，这个功能最初是我为自己开发的，我本身就是一名做产品的工程师，它的核心用户群体其实是专业工程师和设计师。大家在开发应用时，肯定都遇到过这种情况：精心设计的界面，最后却变成了大家都看腻了的紫黄渐变配色。这个功能就是为了让大家能够精准把控细节，比如把内边距调整到精确的像素值。它为用户提供了一套更直观的 “视觉化操作语言”，比纯文本指令的精度更高。 而且就算不使用侧边栏，你也可以直接点击页面元素，随时输入提示词下达指令。借助这个功能，你可以在几秒内同时启动六个 Agent。如果开启热重载功能，你的网站会实时呈现修改效果，用起来其实还挺有意思的。 提问者 2：我特别喜欢你们的浏览器 Agent，一直在用。但我发现一个小瑕疵：我想持续迭代优化设计方案，可 Agent 总是会中断我的工作，直接提交代码合并请求。未来有没有可能实现不间断的持续迭代？ Jason Ginsberg：当然可以。未来的发展方向就是让 Agent 具备自主评估能力，根据需求长时间持续运行、循环迭代。现在的调试模式还需要人工点击按钮来确认日志信息，但这只是过渡方案。理想的状态是，Agent能够自主完成评估、迭代，直到彻底解决问题。 提问者 3：我不知道你是否深度参与 Agent 相关的研发工作，但我注意到 Cursor 的内存管理功能做得很好。它可以根据工程师个人、部门乃至整个公司的偏好、规则和流程，自主管理相关信息。我们都知道，信息和上下文对 Agent 来说至关重要。请问你们有没有计划进一步拓展和升级这个功能？尤其是在长上下文处理方面，你们有什么思路？ Jason Ginsberg：我们正在进行大量的实验和探索。目前已经落地了规则管理、内存记忆、技能库等多个功能模块。现阶段，我们主要在研究高效的信息摘要技术。另外，借助我们的自研模型，我们也在探索让模型自主识别对话或代码中反复出现的关键信息。当然，跨组织的信息共享功能也很值得探索。不过这里有个需要注意的点，相关规则和信息可能会随着模型的迭代而过时。所以我们必须确保用户能够轻松更新这些内容，避免被过时的规则束缚。 提问者 4：关于你们发布的 Composer 模型，我认识一些开发者，他们基于 Gemini 模型微调了一个医疗领域的专用模型。但他们发现，这个微调后的模型效果还不如直接用原生 Gemini 模型做单次提示词调用。他们分析的原因是，微调模型需要持续维护，要跟上 Gemini 等基础模型的更新节奏。请问你们是如何制定策略，确保 Composer 模型不会落伍的？ Jason Ginsberg：你说的是 Composer 模型，对吧？我们会持续对它进行迭代优化，它并不是一个静态的模型。我们的核心关注点，是在速度和智能之间找到最佳平衡点，满足 Cursor 用户在大部分场景下的需求。不过在长上下文处理这类特定领域，我们确实还有提升空间。 提问者 5：我自己是产品经理，一直在用 Cursor 做原型开发，甚至在团队里还客串设计师，用它替代 Figma。我很好奇，有没有用户是在使用 Cursor 之前，从未安装过任何集成开发环境（IDE）的？这类用户会不会成为你们未来重点关注的群体？毕竟现在的编码 Agent 已经足够强大，很多工作都能在上面完成。 Jason Ginsberg：坦白说，我们目前并没有把这类用户作为核心关注点。当然，我们认同工具的使用门槛确实需要不断降低，而且 Cursor 的易用性也在持续提升，比如新增的浏览器工具对设计师就很友好。但我们的核心目标，其实是赋能顶尖工程师。我们一直在思考：如何让世界上最优秀的工程师变得更加强大？在这个过程中，我们开发的工具自然会惠及更多人群。不过在产品优化方面，我们确实还有很多工作要做，如优化新手引导和环境配置流程。毕竟设计师和产品经理在配置 GitHub 等工具时，经常会遇到困难。我们希望通过优化这些环节，吸引更多用户尝试 Cursor。 提问者 6：我一直在尝试用 Cursor 做智能合约的验证矩阵构建和试运行逻辑测试。请问在深度质量检测和安全加固方面，有没有什么不太为人知的实用工作流可以推荐？或者刚才提到的调试工具能不能派上用场？我对智能合约的质量检测特别感兴趣。 Jason Ginsberg：说实话，我们正在尝试让 Agent 自主完成测试工作，不过这项功能目前还没有完全发布。对于从事质量检测工作的人员来说，我强烈推荐试试我们刚发布的调试模式。这个功能定位问题的逻辑非常清晰，几乎可以说是确定性的，用起来会很有帮助。 提问者 7：您认为未来两到四个月，Cursor 面临的最大机遇是什么？会不会是语音 Agent？ Jason Ginsberg：我觉得机遇不在于语音 Agent。用户现阶段最核心的需求，其实是让 Agent 变得更智能、运行时间更长、能处理的任务更多。现在的很多 Agent，本质上只是在 “读取代码”，并不能真正判断修改后的代码是否有效。未来的发展空间非常大，我们可以投入更多算力，让 Agent 承担更多人类目前负责的校验工作。我觉得未来三到六个月，整个行业都会迎来巨大的变革，非常值得期待。 参考链接：https://www.youtube.com/watch?v=dKSGK-fPFyU