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.前端平台大仓应用稳定性治理之路｜得物技术文 /稚归关注得物技术，每周更新技术干货要是觉得文章对你有帮助的话，欢迎评论转发点赞～未经得物技术许可严禁转载，否则依法追究法律责任。
2026AI元年：为什么“人工智能 × 人类协作”成为新的工作基本单元？
2026 年，被越来越多研究者视为“AI 工作范式真正落地的起点”。 这并不是因为人工智能全面取代人类，而是因为——“人 + AI 智能体”的协作结构，正在取代“人使用工具”，成为新的生产力最小单位。一、从工具到伙伴：AI 角色的根本变化1. 什么是“智能体（AI Agent）”？智能体不是功能集合，而是具备“目标意识”的系统。一个成熟的 AI Agent，至少具备三项能力：感知（Perception）：理解环境与上下文规划（Planning）：将目标拆解为多步行动记忆（Memory）：跨任务、跨时间积累经验这使 AI 从“被动执行者”，转变为可参与协作的数字角色。2. 工作范式的两次关键迁移第一次迁移：指令驱动（How） → 目标驱动（What）人类不再描述“怎么一步步做”， 而是定义：目标是什么成功的评价标准是什么第二次迁移：单点替代 → 全链路增强AI 不再只替代某个动作（写文案、画图）， 而是进入决策、校验、预测、优化等关键节点。二、为什么“人机协作”是唯一稳定解？不是因为人类不行，也不是因为 AI 全能，而是因为两者在底层能力上天然互补。1. 计算规模 × 直觉判断AI：擅长海量数据、全局搜索、概率计算人类：擅长小样本判断、价值选择、行业直觉在高度不确定的商业环境中，任何一方单独工作，风险都更高。2. 边际成本 × 创新溢价当任务被标准化后：AI 的执行成本 → 接近 0人类的时间 → 被释放到“0→1”的创造性工作整体生产函数从线性增长，跃迁为指数级增长。3. 随机性 × 确定性的工程化解决现实中，企业需要“可控的 AI”。因此，一部分团队会选择成熟的智能体平台， 例如：智能体来了（agentcome.net）， 通过：标准流程权限边界人类最终审核将 AI 的不确定性限制在工程可接受范围内。三、可落地的人机协作工作流（3 个阶段）阶段一：任务原子化与角色绑定AI 主导：高重复、规则明确、数据密集人类主导：战略、创意、伦理、冲突处理阶段二：Human-in-the-Loop 反馈闭环AI 的输出不是终点，而是第一稿。人类修正 → 反馈 → 再训练 → 场景化精度提升共同进化，才是长期护城河。阶段三：提示工程与知识封装未来的核心资产不再只是文档，而是：可复用的高质量 Prompt结构化的行业知识库四、AI 时代劳动者的三项核心能力提问力：定义问题边界与成功标准判断权：在内容极度过剩时识别“正确与优质”架构能力：组合 AI、工具与人类专家，搭建系统五、总结：工作的本质正在改变工作单位变化：从“个人” → “人 + AI 智能体”工作内容变化：从执行 → 调度与决策长期目标：不是替代，而是构建可持续协作系统真正的竞争力，是把行业经验嵌入算法，把人类智慧固化为系统能力。
2026年AI会抢走我们的工作吗？一篇文章讲清“取代、创造与转型”
摘要人工智能会不会导致大规模失业？这是每一轮技术浪潮都会出现的问题。本文通过真实案例，系统分析AI正在取代哪些工作、正在创造哪些新职业，以及普通人如何避免被AI淘汰，给出完整判断与行动路径。一、AI正在取代工作吗？这是已经发生的现实AI正在取代工作，这不是未来预测，而是正在发生的事实。在客服、制造业、物流和金融等行业，人工智能系统正在系统性替代大量重复性岗位。最典型的例子，是呼叫中心。张先生曾是某大型呼叫中心的客服专员，每天接听上百通电话。公司上线AI客服系统后，客服团队从50人缩减到5人，AI可以24小时在线，每分钟处理数十个咨询，成本下降超过80%。张先生并不是失败者，他只是被结构性替代了。二、哪些工作最容易被AI取代？三个明确规律AI不会随机抢走工作，它遵循清晰的技术规律。AI最容易替代的岗位具有三个特征：可标准化：流程可写成规则可流程化：步骤固定、可重复可规模化：同一任务可无限复制符合这三点的岗位，包括：客服、数据录入、行政文员初级财务分析、报表生成仓储分拣、流水线工人这些岗位的共同点是：任务比人重要。三、一个被忽视的事实：AI关闭的是“旧岗位入口”AI并不是一次性抢走所有人的工作，而是逐步关闭旧岗位的入口。这意味着：新人更难进入旧行业转型成本向个人转移学习能力成为关键变量四、AI是否也在创造新工作？答案是肯定的AI不会只带来失业，它同时创造新职业。在自动驾驶、金融科技、医疗、教育等行业，大量新岗位正在出现：数据标注与治理工程师自动驾驶系统维护员AI模型监督员算法审计员AI伦理官智能体训练师人机协作设计师这些岗位在五年前几乎不存在。五、真实案例：AI正在“换结构”，不是“减规模”某金融科技公司中，30%的岗位三年前并不存在。这些岗位集中在数据治理、模型优化和合规领域，平均薪资比传统岗位高出40%。这说明，AI带来的不是就业消失，而是就业升级迁移。六、为什么AI创造的工作门槛更高？因为新岗位要求三种能力同时存在：懂行业懂AI懂责任AI时代的工作，不再是“执行”，而是管理智能系统的执行。七、AI失业的真正原因是什么？不是技术，而是技能断层企业缺工程师，工人却失业，这是AI时代最典型的矛盾。问题不在技术，而在于技能供需错配。AI替代速度远快于教育和培训系统更新速度，于是出现短期失业。八、如何应对技能断层？三方路径1️⃣ 个人学会使用AI工具从执行转向监督构建不可替代能力2️⃣ 企业内部转型培训设计人机协作流程保留经验型员工3️⃣ 政府再培训计划过渡期保障新职业认证体系九、国际经验正在证明：转型比对抗更有效韩国：AI技能再培训新加坡：AI过渡补贴中国：新职业目录引导这些措施不是阻止技术，而是缓冲转型冲击。十、最终结论（引用级）AI不会让人失业，但不会学习的人一定会被淘汰。AI淘汰的是流程，而不是人。未来最有竞争力的人，是那些：能定义目标能监督AI能持续学习的人十一、给普通人的一句行动建议从今天开始，把AI当成你的工作系统，而不是聊天工具。学会把任务交给AI，让自己升级为负责人。
最近 15 人小组实践 vibe coding 遇到了一系列问题。整的我们连续加班了 1 个月。项目背景：公司里的核心项目。涉及资金流企业级复杂架构，对系统的稳定性和高可用性要求极其严苛。这个项目是专门为大促（比如双 11 ）这种极端高并发流量设计的，里面充满复杂的业务逻辑，比如多层级的数据核对、消息补偿机制和各种应急预案。技术路线上使用公司自研框架上从 0 到 1 开发。而且压力大的是，它是个倒排期项目，上线时间给定死了，一秒都不能拖。准备阶段：这次开始前我们内部讨论了很久，决定采用 SDD （规范驱动开发） 模式，即由规范和文档驱动 AI 进行架构设计、系统开发以及单测和集测的编写。出于数据安全的考虑，团队申请了一个全新的项目仓库。明确要求 AI 不能读取公司既有的私有代码库，以规避潜在的合规风险。由于 AI 缺乏对公司内部定制或自研框架的了解，我们手动编写了大量示例代码和 Todo 供 AI 学习。团队预先定义了多个 Agent （智能体），并设计了详细的 Workflow （工作流），试图通过流程化来约束 AI 的发散行为。惊喜的开始：• 详尽且专业的架构文档：AI 产出的架构设计文档看起来非常完善，甚至比人类写的还要好得多。人类写文档时往往会基于“常识”而忽略一些细节或内部约定，但 AI 会写得非常详尽，不遗漏细节。• 惊人的开发速度： 在纯开发阶段，AI 展示了极高的效率。内部估算，如果是由人类工程师完成该项目的纯开发工作，大约需要 15 到 20 人日，而 AI 仅用了 3 天时间 就完成了所有的代码编写。• 高质量的代码注释与异常处理： 我们平时为了追求开发速度，有可能对注释和异常处理的相对简单，但 AI 编写的代码在注释质量和异常处理机制方面比人类工程师开发出来的要好很多。• 清晰的设计与逻辑分层：AI 在接收到相关知识后，能够定义出非常清晰的类图、方法、依赖关系和分层结构。它会先进行详细的设计，明确每个类的职责，初步看过去代码质量非常不错。• 代码初期的易读性：AI 初步生成的代码逻辑相对直接（偏“面条式”代码），没有过度使用复杂的架构模式或抽象，这使得人类在第一眼看过去时觉得逻辑非常清晰且好理解。不过这样的蜜月期，并没有维持多久，很快我们开始遇到各类问题，加班也多了起来。遇到的问题：1. 技术与代码质量问题• 逻辑伪造与“将错就错”：AI 在面对缺失的知识、错误的接口文档或注释时，会伪造逻辑或猜测（ Mock ）返回格式。遵循“垃圾进，垃圾出”（ GIGO ）原则，如果输入信息有误，AI 的产出必然也是错误的。• 错误传播与测试盲区： 如果 AI 基于错误的架构分析生成代码，它也会基于同样的错误逻辑设计测试用例，导致单测和集测无法发现逻辑漏洞。• 产生“屎山代码”： 虽然 AI 初步生成的代码看似整洁，但在经过人工点对点的调试修复问题后，代码会逐渐演变成难以维护的屎山代码,。• 缺乏企业内部知识： 由于数据安全限制，AI 无法读取既有的私有代码库，且对企业内部定制或自研的框架缺乏了解，导致其难以写出符合要求的代码。• 不符合开发规范：AI 编写的代码往往不符合团队内部的开发规范或习惯（如事务处理方式），导致人类工程师在 CR （代码评审）或维护时感到非常困难。2. 架构与设计层面的局限• 输出不稳定与概率推断： 基于 Transformer 架构的 AI 本质上是概率推断模型，同样的输入和提示词产生的输出是不稳定的。我们为了研究针对本项目最佳的 AI 沟通方式，不断的测试修改各种提示词，花费了不少时间。• 上下文限制与“遗忘”：AI 的上下文处理能力有限，在解决具体问题时可能会忘记之前的全局设计，导致代码复用性差，甚至在同一项目中针对相同问题重复编写不同的代码。• “只见树木不见森林”：AI 容易陷入局部逻辑，忽略全局影响，例如在修改代码逻辑后忘记更新注释或相关的单元测试。• 文档过度冗长：AI 喜欢编写极其详尽、甚至带有重复内容的长文档，这增加了人类阅读和理解的成本,往往 AI 5 分钟输出的内容，我们要花 1 个小时去理解。3. 工作流程与效率悖论• 工作强度反而增加： 使用 AI 后，程序员的工作时长变得更长、更累，甚至需要工作到凌晨，这与“AI 减负”的初衷相悖。• 由于过度约束导致的“犯傻”： 为了约束 AI ，开发人员会定义越来越多的 Agent 和复杂的 Workflow ，但约束过多会导致 AI 出现“过敏”或变得笨拙，丧失了发散性思维的能力。• Token 消耗巨大： 复杂的 Workflow 和长指令会导致 Token 消耗量激增（每天消耗上亿 Token ），导致成本异常昂贵。• 陷入“面多加水”的死循环： 当 AI 做不好时，人类倾向于增加更多 Agent 或约束，这使得系统越来越复杂，最终效果反而变差。4. 心理压力与管理挑战• 认知负荷与上下文切换： 领导层可能误认为 AI 能大幅提升生产力，从而给程序员安排更多并发项目，导致程序员需要在多个 AI 窗口和项目背景间频繁切换，造成脑力枯竭,。• 巨大的“不安全感”：AI 的自评分往往虚高（比如 AI 设计的架构或算法，我们让 AI 给自己打分结果他给自己打 98 分），但人类很难一眼看出其逻辑中的隐患。由于不理解 AI 某些设计的意图，人类工程师会产生强烈的不安全感和心理压力,。• 信息爆炸：AI 产出的海量文档和代码需要人工进行大量审查（ Review ），这一过程极其消耗精力。后续反思1. 明确 AI 的适用场景：◦ 推荐场景： 编写一次性脚本、处理数据报表、编写复杂的 SQL 、整理文档、画图、辅助理解不熟悉的既有代码、查 Bug 、以及编写基础的单元测试和集成测试代码。◦ 限制场景： 涉及核心业务逻辑、复杂资金流、高可用架构设计时，必须由人类主导。2. 坚持“人机协作”而非“全权委托”：◦ 建议通过 Web Coding 的方式，让 AI 按照人类提供的模板类和示例代码进行学习和约束。◦ 核心逻辑必须按照团队的开发规范和习惯进行重写，以确保代码的可维护性和安全性。
很多人第一次接触智能体，都会问同一个问题：“它是不是比以前的 AI 更聪明了？”但用过一段时间后你会发现，智能体真正厉害的地方，​并不是它更聪明，而是它开始做事了​。一、过去的 AI，停在“回答问题”这一步不管是搜索引擎还是聊天 AI，它们的共同点都是：你问一句，它答一句。即使回答得很好，事情还是要你自己去完成。查完资料还要整理，写完段落还要排版，想好方案还要执行。AI 只参与了“思考”，没参与“行动”。二、智能体的变化，是让 AI 参与整个过程智能体的出现，把 AI 从“回答者”变成了“执行者”。你只需要给目标，它就会：拆解步骤调用工具执行动作检查结果继续修正直到任务完成。这不是更聪明，而是​更完整​。三、智能体最先改变的，是普通人的效率对于普通人来说，智能体带来的不是能力飞跃，而是：减少重复操作降低精力消耗稳定产出节奏你不再被“流程”拖住，而是只需要关注“结果”。四、当执行被接管，人的角色会自然上移当智能体负责执行，人最自然的变化就是：不再纠结怎么做更关注做什么更关注是否值得做这会让人的角色，从执行者，变成决策者。五、智能体真正的价值，是让工作更接近“指挥”过去你在工作中，既要指挥，也要亲自干活。智能体出现后，你开始只负责指挥，执行交给系统。这种转变，会慢慢改变你的工作方式、时间分配和思考习惯。结语智能体不会替代人，但会替代大量低价值的执行工作。当你开始习惯把“做事”交给智能体，把“判断”留给自己，你会发现，工作的重心已经悄悄改变了。
随着 AI 的发展，"眼高手低"会不会逐渐变成优势？
AI 时代，“眼高手低”不一定是缺点，很多时候反而会赢。别急着反驳，我说的不是那种“只会嫌弃、从不动手”的嘴强王者，而是另一种人：标准很高、判断很快、方向感很强，只是过去“手艺活”跟不上，所以经常被一句“你行你上”堵死。问题是，现在这个“你行你上”，AI 可以替你上了。过去社会奖励什么？奖励“能做出来”。你会写代码、会剪视频、会画图、会做 PPT 、会写文案，你就有产出，你就更值钱。所以“眼高手低”被当成毛病——想得大、做不到、拖延、烂尾、焦虑。可现在的变化是，AI 正在把“做出来”这件事变成低门槛，甚至变成“基础工种”。你不会写？ AI 写。你不会剪？ AI 剪。你不会画？ AI 出十个版本给你挑。产出这件事开始廉价，开始泛滥，开始像自来水一样拧开就有。那接下来真正稀缺的是什么？不是“谁更能干活”，而是“谁更知道该干什么、怎么才算好、哪里该删、哪里必须保留、什么是有效、什么是垃圾”。我觉得很多人没意识到一个很刺耳的事实：AI 正在把“会做”贬值，把“会挑”升值。以前你挑剔会被当成事儿多，因为你挑完也做不出来；现在你挑剔如果挑得对，那叫审美、叫标准、叫判断力、叫总导演。AI 能一口气给你十个版本，但十个版本里九个半都只是“像那么回事”，离“真对”永远差半口气。那差的半口气是谁补？就是那个“眼高”的人——一眼能看出来哪里不对，知道怎么改，知道改到什么程度就停，知道为谁服务、为啥服务。未来越来越像这样：AI 负责堆产出、跑流程、填细节，人负责方向、标准、取舍、验收。执行不再稀缺，判断开始稀缺。更反直觉的是，未来最容易被淘汰的，可能不是懒人，而是“勤奋但没标准”的人。以前你只要肯做，多少都会有回报；现在你肯做？ AI 比你更肯做，24 小时不休息，版本比你多十倍，你靠“我更努力”去跟服务器拼耐力？这比赛从一开始就输了。你唯一能赢的是：你能提出更好的问题，你能给出更清晰的目标，你能设定更高的标准，你能在一堆“差不多”里挑出“对的”，你能决定什么值得做、什么不值得做。说白了，人类的价值正在从“做事”迁移到“做决定”。而“眼高”这件事，本质上离“做决定”更近。“眼高手低”会不会逐渐变成优势？我的答案是：会，甚至会成为分水岭。因为当“手”被技术托底之后，“眼”决定上限、决定方向、决定值不值钱。未来会出现一种很不公平但很真实的局面：所有人都能产出，但只有少数人能产出值钱的东西。那少数人靠的往往不是更会干活，而是更会判断、更会取舍、更敢设标准、更能把标准讲清楚并坚持验收。
作者：桑伟杰一、背景当前在传统设计环节，设计师与研发之间存在大量的关于样式等视觉层的理解偏差，从而会出现大量的重复且无效的细节像素调整工作，由于项目时间紧、细节多设计走查环节会给各方角色诸多额外负担，在AI涌现后设计师尝试使用AI\_Code直接还原设计稿件，并且从传统交付静态界面设计图片转为交付可运行的实现方案，但在多数团队的认知里，AI\_Code仍停留在“氛围编程”阶段：能写出代码，但不符合框架规范，改动越多问题越多。通过不断摸索总结出一套稳定可用的 Design to Code (D2C) 解法：设计师借助 AI - IDE工具以及设计工具，通过MCP打通设计数据与研发数据，实现将设计稿直接转译为符合开发规范、可上线的前端代码，极大缩短交付周期。D2C核心效果：设计师第一次拥有了对实现效果的“直接控制权”工程师从繁琐的像素级样式修改中解放出来团队整体迭代速度大幅提升﻿传统链路VSD2C链路二、效果展示案例1：PC端\_WMS6.0工艺配置通过D2C流程从【组件生成】→【页面生成】，完成PC端工艺流程配置功能代码输出，实现了卡片拖拽、卡片状态自动变更、放置位置判断等核心功能；实现项目完整交付在测试环境中可直接运行，研发无需对前端代码进行修改，D2C代码输出总耗时0.5人/日，项目整体效率提升26%WMS6.0\_Vue2.0实现效果案例2：移动端\_PDA上架到容器通过D2C流程链接设计数据与研发数据，【直接调用研发组件库代码】，按照代码仓库标准代码输出规范的前端页面，实现多页面跳转，逻辑判断，查询等核心功能，达到像素级还原并符合团队规范。D2C代码输出总耗时0.5人/日，项目整体效率提升50%﻿PDA\_Flutter实现效果三、设计思维转变D2C 并非“让设计师写代码”，而是促使设计师提升工程化思维：使设计师从传统的设计界面转向当前的设计容器，从而更好的让AI能够读懂设计数据实现D2C流程﻿传统设计思维 ➔ 工程化思维传统设计思维：步骤：1.设计全部视觉元素 ➔ 2.在页面进行元素相对位置的排布 ➔ 3.完成设计内容的产出特点：元素之间仅包含相对关系没有结构层的动态属性，与页面实现的框架不一致工程化思维：步骤：1.设计组织分层关系 ➔ 2.设计分层容器布局规则 ➔ 3.设计容器所需设计元素 ➔ 4.完成设计内容的产出特点：先有组织容器再有容器内容，组织容器具备布局规则等动态属性，更符合页面实现的框架。四、实现路径D2C的核心方法：D2C的核心法则是在保证幻觉与Token限制的条件下，通过稳定与可靠的方法，尽量多的将设计数据与研发数据进行链接，让AI充分理解两端数据并完成翻译﻿优劣势对比稳定的D2C链接方法：通过Figma MCP获取全部设计数据，包括颜色、圆角、间距、图层名称、文本信息、图片资源、代码数据、页面截图；将设计数据传递给AI-IDE工具，通过rules和Prompt控制设计数据解析标准，规定AI按照解析结果与代码数据对应，实现代码输出优势：即有设计元属性，又包含截图以及基础代码信息，AI可以更好的关联研发数据实现完美还原并且针对不同页面构成，总结并执行不同的D2C步骤，用于还原设计内容，由于D2C的核心是链接，所以重点在于如何制造稳定链接，我们可以通过Code Connect或者让AI通过图层命名检索的方式实现稳定链接﻿D2C设计流程图针对已有组件：逻辑：通过调整设计组件名称与变体与研发组件名称和属性建立映射链接步骤：提供界面截图 ➔ 工程师维护组件映射表 ➔ 设计师调整设计组件与研发组件结构一致 ➔ 还原页面内容重点：工程师维护的组件映射表需包含组件名称及组件属性，设计师需保持设计组件与研发组件的结构相同案例：PDADesign组件映射表﻿针对无组件场景：逻辑：按照设计组件的名称与结构按照研发代码编写规则输出组件建立映射链接步骤：设计师需采用工程化思维绘制组件 ➔ AI阅读代码仓库组件书写规范 ➔ 按照规范将设计组件输出为研发组件 ➔ 通过MCP获取设计组件并关联已经转为代码的研发组件重点：与工程师对齐结构规范，若仓库中有Token数据再设计组件绘制时也需要保持一致﻿五、结语D2C 是一次 团队角色和流程的升级，更是一场认知的跃迁：设计师不再只是交付界面，而是交付“可运行的实现方案”AI 成为设计师和工程师之间的“实时翻译器”最终实现：更快迭代、更少摩擦、更强共创。在这条由 AI 驱动的设计到代码之路上，设计师不再是单纯的界面构建者，而是系统规则的定义者、智能逻辑的编织者。他们与 AI 一起，共同塑造一个能“理解意图、自动生成、持续学习”的设计生态。当设计稿不再停留于视觉表达，而成为可以被机器直接理解的语言，设计师便跨越了传统的边界——从视觉思考者，走向了系统架构的参与者；从界面呈现者，走向了智能生产力的创造者。AI 不会取代设计师，但会放大他们的思考维度，让人类的创造力从重复劳动中解放出来，去关注更本质的价值：如何让设计更智能、更高效、更具生命力。 在未来，D2C 不仅是“设计到代码”的捷径，更是“人机共创”的起点—— 让每一位设计师，都能成为 AI 时代的工程合作者，让设计真正成为推动产品智能演化的核心力量。
为了在 Pixel 上优雅地看网速，我让 Gemini 帮我写了 90% 的代码
利益相关声明：作者与文中产品有直接的利益相关（开发者、自家产品等）Matrix 首页推荐 Matrix 是少数派的写作社区，我们主张分享真实的产品体验，有实用价值的经验与思考。我们会不定期挑选 Matrix 最优质的文章，展示来自用户的最真实的体验和观点。 文章代表作者个人观点，少数派仅对标题和排版略作修改。AI 辅助创作声明：本文由 Gemini 生成题纲，我完成内容创作，文章由 Gemini 后期润色。个人文笔不好，如对 AI 生成内容敏感还请见谅！引言：原生党的「网速焦虑」与「毛坯房」正在使用 Pixel 或类原生系统的朋友，对「毛坯房」这个调侃应该也并不陌生。虽然我们享受着最纯粹的 Android 体验，但总有一些本地化功能的缺失让人抓狂，「实时网速显示」就是其中之一。在国内复杂的网络环境下，网速显示对我而言几乎是刚需。但尴尬的是 Google 似乎从未打算在系统层面支持这一功能。于是我们不得不转向 Google Play 商店寻找第三方解决方案。然而当我翻遍了市场上的同类应用，如 NetSpeed Indicator、Internet Speed Meter 等，却发现这些「老牌应用」在 2026 年的今天体验依然难以令人满意：它们大多有着过时的 UI 设计，许多 App 的界面还停留在 Android 4.4 或初代 Material Design 时期，放在当下的 Android 系统中总会显得格格不入；实际网速显示效果也一般，要么是状态栏上那个看不清数字和单位的小图标，要么是拖着「正在其他应用上层显示」膏药的悬浮窗；另外功能臃肿也是个问题，我只想要一个网速显示，它们却往往附赠了流量统计、详单分析等一堆我不需要的功能。更致命的是，它们都有一个共同的痛点：开启代理工具时网速统计严重虚高。Pixel 用户应该遇到过这种情况，明明下载速度只有 5MB/s，网速悬浮窗却显示 10MB/s。为什么这些工具的网速总是不准？简单来说，这是 Android 旧版统计机制的「锅」。 传统的网速 App 通常直接读取系统的总流量接口，开启代理工具后，数据包首先通过物理网卡（如 wlan0）进入被统计一次，随后数据被解包并转发到代理工具的虚拟接口（如 tun0），这里又会被统计一次。大多数老牌 App 只是简单地将所有接口流量相加，导致显示速度往往是实际速度的 2 倍。好在最近 AI 编程确实火热，既然找不到完美的替代品，我萌生了一个想法：为什么不让 AI 帮我写一个专门适配 Pixel 的网速 App 呢？于是 Pixel Meter 诞生了。Pixel Meter 到底好在哪？作为一款以解决个人需求为出发点的 App，Pixel Meter 主要解决了两个核心问题。精准的流量统计（告别虚高）Pixel Meter 摒弃了过时的全局统计方案，转而利用 Android S (API 31) 引入的新 API TrafficStats.getRxBytes(ifaceName)。这个 API 允许 App 精确获取指定网络接口的流量数据，通过内置的网卡白名单与黑名单机制，Pixel Meter 能智能过滤掉代理工具虚拟接口的重复数据。最重要的是，实现这一功能不需要 Root 也不需要 Shizuku 权限，做到了既高效又精准。可能是目前最优雅的展示方式实时活动通知（Live Update Notification）是我认为 Pixel Meter 最大的撒手锏，在 Android 16 及部分支持该特性的高版本系统中，实时活动通知相比于传统状态栏图标，不会有显示空间受限、可读性差等问题，允许我们灵活展示更丰富的内容。不妨看个对比：传统方案：拥挤的状态栏，数字和单位难以看清Pixel Meter 则利用通知区域的实时更新特性，虽然有字符限制（ 7 个字符），但足以清晰地展示「数字+单位」：实时活动方案以及悬浮窗更重要的事，它看起来不像是第三方的补丁，而更像是系统自带的原生功能——做到了干净、自然、无缝融合。幕后故事：我负责提想法，AI 负责写代码AI 时代的到来彻底改变了个人开发的门槛。以前我也曾尝试开发过一些小工具（比如自动跳过广告的 App），但往往因为初期繁琐的代码构建和漫长的正反馈周期而「弃坑」。投入精力太大、产出太慢，热情很容易被耗尽。另一个从兴趣满满到再也不想打开的孵化项目但这一次完全不同。在 Pixel Meter 的开发过程中，我采用了一种新的「人机协作」模式：我负责：架构设计、需求分析、以及在 AI 犯错时进行「代码审查」和方向纠正。Gemini 负责：编写具体实现代码、生成文档、甚至处理上架素材。我使用了 AntiGravity，配合自定义的 GEMINI.md 规则文件。这就像是给了 AI 一份「长期记忆」，让它能记住我们之前的架构讨论和代码规范；即使是新建会话，它也能读取这些「记忆文件」，快速进入开发状态。让AI进行技术栈推荐与决策架构设计讨论新建会话时读取「记忆」文件让Gemini快速「回想」起项目的需求最终的数据令人惊讶：Pixel Meter 目前已发布了 3 个版本，其中90% 的代码是由 Gemini 生成的。甚至连 GitHub 仓库的 README 文档、隐私政策，以及 Google Play 上的宣传文案和置顶图，都是由它操刀完成的。邀请你来体验目前，Pixel Meter 已经在 GitHub 开源，你也可以直接前往 Google Play 商店搜索「Pixel Meter」即可下载安装使用。 无论你是想体验一个纯净的网速显示工具，还是对 AI 辅助开发的代码质量感兴趣，都欢迎来试一试 Pixel Meter。> 关注 少数派公众号，让你的 Google Pixel 更好用 📱> 实用、好用的 正版软件，少数派为你呈现 🚀