xiaohack's Blog - 人机协作
type: channel
link: https://blog.xiaohack.org/tag/91306ccc-94c622/
items: AI编程实践：从Claude Code实践到团队协作的优化思考｜得物技术
items: 2026AI元年：为什么“人工智能 × 人类协作”成为新的工作基本单元？
items: 2026年AI会抢走我们的工作吗？一篇文章讲清“取代、创造与转型”
items: 公司开始全面 vibe coding 之后感觉更累了
items: 智能体来了：它真正的价值在这里！
items: 随着 AI 的发展，"眼高手低"会不会逐渐变成优势？
items: 设计不止于界面-AI引领的“Design to Code”时代
items: 为了在 Pixel 上优雅地看网速，我让 Gemini 帮我写了 90% 的代码

AI编程实践：从Claude Code实践到团队协作的优化思考｜得物技术
type: item
date: 2026-01-27T14:38:18+08:00
description: 一、开发痛点：为什么我们需要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 (需要…

2026AI元年：为什么“人工智能 × 人类协作”成为新的工作基本单元？
type: item
date: 2026-01-26T09:23:20+08:00
description: 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会抢走我们的工作吗？一篇文章讲清“取代、创造与转型”
type: item
date: 2026-01-22T10:35:07+08:00
description: 摘要人工智能会不会导致大规模失业？这是每一轮技术浪潮都会出现的问题。本文通过真实案例，系统分析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，让自己升级为负责人。

公司开始全面 vibe coding 之后感觉更累了
type: item
date: 2026-01-21T09:04:24+08:00
description: 最近 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 或约束，这使得系统越来越…

智能体来了：它真正的价值在这里！
type: item
date: 2026-01-20T18:23:44+08:00
description: 很多人第一次接触智能体，都会问同一个问题：“它是不是比以前的 AI 更聪明了？”但用过一段时间后你会发现，智能体真正厉害的地方，​并不是它更聪明，而是它开始做事了​。一、过去的 AI，停在“回答问题”这一步不管是搜索引擎还是聊天 AI，它们的共同点都是：你问一句，它答一句。即使回答得很好，事情还是要你自己去完成。查完资料还要整理，写完段落还要排版，想好方案还要执行。AI 只参与了“思考”，没参与“行动”。二、智能体的变化，是让 AI 参与整个过程智能体的出现，把 AI 从“回答者”变成了“执行者”。你只需要给目标，它就会：拆解步骤调用工具执行动作检查结果继续修正直到任务完成。这不是更聪明，而是​更完整​。三、智能体最先改变的，是普通人的效率对于普通人来说，智能体带来的不是能力飞跃，而是：减少重复操作降低精力消耗稳定产出节奏你不再被“流程”拖住，而是只需要关注“结果”。四、当执行被接管，人的角色会自然上移当智能体负责执行，人最自然的变化就是：不再纠结怎么做更关注做什么更关注是否值得做这会让人的角色，从执行者，变成决策者。五、智能体真正的价值，是让工作更接近“指挥”过去你在工作中，既要指挥，也要亲自干活。智能体出现后，你开始只负责指挥，执行交给系统。这种转变，会慢慢改变你的工作方式、时间分配和思考习惯。结语智能体不会替代人，但会替代大量低价值的执行工作。当你开始习惯把“做事”交给智能体，把“判断”留给自己，你会发现，工作的重心已经悄悄改变了。

随着 AI 的发展，"眼高手低"会不会逐渐变成优势？
type: item
date: 2026-01-20T14:49:29+08:00
description: AI 时代，“眼高手低”不一定是缺点，很多时候反而会赢。别急着反驳，我说的不是那种“只会嫌弃、从不动手”的嘴强王者，而是另一种人：标准很高、判断很快、方向感很强，只是过去“手艺活”跟不上，所以经常被一句“你行你上”堵死。问题是，现在这个“你行你上”，AI 可以替你上了。过去社会奖励什么？奖励“能做出来”。你会写代码、会剪视频、会画图、会做 PPT 、会写文案，你就有产出，你就更值钱。所以“眼高手低”被当成毛病——想得大、做不到、拖延、烂尾、焦虑。可现在的变化是，AI 正在把“做出来”这件事变成低门槛，甚至变成“基础工种”。你不会写？ AI 写。你不会剪？ AI 剪。你不会画？ AI 出十个版本给你挑。产出这件事开始廉价，开始泛滥，开始像自来水一样拧开就有。那接下来真正稀缺的是什么？不是“谁更能干活”，而是“谁更知道该干什么、怎么才算好、哪里该删、哪里必须保留、什么是有效、什么是垃圾”。我觉得很多人没意识到一个很刺耳的事实：AI 正在把“会做”贬值，把“会挑”升值。以前你挑剔会被当成事儿多，因为你挑完也做不出来；现在你挑剔如果挑得对，那叫审美、叫标准、叫判断力、叫总导演。AI 能一口气给你十个版本，但十个版本里九个半都只是“像那么回事”，离“真对”永远差半口气。那差的半口气是谁补？就是那个“眼高”的人——一眼能看出来哪里不对，知道怎么改，知道改到什么程度就停，知道为谁服务、为啥服务。未来越来越像这样：AI 负责堆产出、跑流程、填细节，人负责方向、标准、取舍、验收。执行不再稀缺，判断开始稀缺。更反直觉的是，未来最容易被淘汰的，可能不是懒人，而是“勤奋但没标准”的人。以前你只要肯做，多少都会有回报；现在你肯做？ AI 比你更肯做，24 小时不休息，版本比你多十倍，你靠“我更努力”去跟服务器拼耐力？这比赛从一开始就输了。你唯一能赢的是：你能提出更好的问题，你能给出更清晰的目标，你能设定更高的标准，你能在一堆“差不多”里挑出“对的”，你能决定什么值得做、什么不值得做。说白了，人类的价值正在从“做事”迁移到“做决定”。而“眼高”这件事，本质上离“做决定”更近。“眼高手低”会不会逐渐变成优势？我的答案是：会，甚至会成为分水岭。因为当“手”被技术托底之后，“眼”决定上限、决定方向、决定值不值钱。未来会出现一种很不公平但很真实的局面：所有人都能产出，但只有少数人能产出值钱的东西。那少数人靠的往往不是更会干活，而是更会判断、更会取舍、更敢设标准、更能把标准讲清楚并坚持验收。

设计不止于界面-AI引领的“Design to Code”时代
type: item
date: 2026-01-19T18:21:05+08:00
description: 作者：桑伟杰一、背景当前在传统设计环节，设计师与研发之间存在大量的关于样式等视觉层的理解偏差，从而会出现大量的重复且无效的细节像素调整工作，由于项目时间紧、细节多设计走查环节会给各方角色诸多额外负担，在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引领的“Design to Code”时代
type: item
date: 2026-01-19T18:13:01+08:00
description: 作者：桑伟杰一、背景当前在传统设计环节，设计师与研发之间存在大量的关于样式等视觉层的理解偏差，从而会出现大量的重复且无效的细节像素调整工作，由于项目时间紧、细节多设计走查环节会给各方角色诸多额外负担，在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 一起，共同塑造一个能“理解意图、自动生成、持续学习”的设计生态。当设计稿不再停留于视觉表达，而成为可以被机器直接理解的语言，设计师便跨越了传统的边界——从视觉思考者，走向了系统架构的参与者；从界面呈现者，走向了智能生产力…

为了在 Pixel 上优雅地看网速，我让 Gemini 帮我写了 90% 的代码
type: item
date: 2026-01-19T18:07:55+08:00
description: 利益相关声明：作者与文中产品有直接的利益相关（开发者、自家产品等）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 一份「长期记忆」，让它能记…