如何给不同类型的软件制定 AI Workflow
不同类型的软件，适合的 AI Workflow 是不一样的，我大致把它们分成两类：内容型的和功能型的。
#Agent
共 89 篇文章。
从模块化走到生成式
公司最近在做 Widget，也就是一些小的功能控件。看完之后我的第一反应是，这其实就是模块化、组件化思路的又一次形态变化。这个理念从软件开发早期就有，只是每过一个阶段，名字和形态会变一变，回到第一性原理上看，讲的还是同一件事。
构建 AI 数字分身
我比较理想的状态，是以后很多事情都不用我盯着。任务扔进去以后，AI 自己分析、执行、检查、继续往下跑，最好一天 24 小时都可以工作。我只看最后的结果，或者偶尔处理真正需要我的事情。
构建远程AI工作流
中秋出去旅游前，我已经预设了一些任务，准备在旅途中远程连接家里的电脑，让 AI 继续做开发。电脑放在家里也是闲着，想着任务提前安排好，出去玩的时候偶尔看一下进度就行。
AI 是养出来的：从 Eval First 谈领域经验
前段时间我一直在折腾创意可视化。试过不同模型，也写过一些 Skill，效果总差点意思。模型不是做不出来，而是做出来的东西经常“没毛病，但也没什么意思”：页面能跑，图也完整，细节处理得挺认真，可你看完还是会觉得，这不就是换了一种画法吗？
如何最大化利用你的Token
我感觉 AI 现在对我来说，就是一个游戏机，Token 就是游戏币，每天玩得不亦乐乎。只要有一个想法，立刻就能去验证和实现，这种正反馈太强了。
Skill和Agent的区别
给同事分配任务时踩了个坑。我说按构建 Agent 的方式去做，结果收上来的交付物全是 Skill。他们觉得做一个 skill 包就算交差了。
从审美评分到垂直领域专家：AI 视觉评价该怎么做
最近在带新同事做可视化需求时，遇到了一个问题：他们可以结合 AI 把功能做出来，但很难判断做出来的东西好不好。
从 Demo 到生产：AI Agent 工程真正难在哪里
答辩里介绍了不少 AI 与数据可视化结合的实践。有些能力已经能够稳定生成内容，也开始进入实际使用阶段。
沟通的重要性与构建 Agent 的正确思路
现在我们基本要求每个人都能全链路地把事情搞定。但我们做的很多事情不确定性很强，需要大量探索和调研，还经常涉及自己不熟悉的业务。碰到这种情况，能不能找到合适的业务专家就很关键。
OpenAI、Anthropic、Google 与 DeepSeek，到底有什么不同
我后来又看了一轮这些公司的领导者访谈、官方博客和论文。之前的分析不能算错，但确实把它们分得太开了。
AI Coding的Token到底花在哪里
最近在使用 Codex、Claude Code、Kimi Code 这些工具时，我一直有一个疑问：
读《WorkBuddy如何把Agent做成可用产品》：拿着它对照了一遍我们自己的项目
今天看到腾讯技术工程发的一篇文章：从模型到Harness：WorkBuddy如何把Agent做成可用产品，作者 Anne 是 WorkBuddy 团队的策略产品经理，负责研发与办公场景 Agent 的上下文策略。
如何构建一套面向真实业务的模型能力评测框架
Kimi K3 模型发布了，想验证一下它在我们真实的数据可视化业务中到底能做到什么程度。
Vibe Coding近期经验总结
最近我在用 Vibe Coding 的方式开发叙事可视化工作站。项目目前只完成了一部分功能，还在持续开发，但这段时间遇到的问题已经非常多了。
AI协作开发中最容易反复犯的七类错误
最近我在用多个 AI Agent 并行推进一个客户端改造项目。
我们到底在做什么：AI视频客户端其实是一套Harness
最近在重新拆 AI 视频项目的任务，有两件事让我停下来想一个更基础的问题：我们到底在做什么。
让AI自主开发跑起来：先写验收，再拆任务
最近我在尝试把一批开发需求交给多个 AI 执行。这批需求的一部分来自会议录音转写：里面有产品边界、技术方案、人员分工，也有口误、同音字和讨论到一半又被推翻的想法。最直接的做法是把转写总结成任务列表喂给 AI，等它写完再补测试和自测。
提取博客知识为Skill
按此标准，博客中约 5%（~60 篇） 有 Skill 价值，其中真正高价值、可直接抽取的约 15-20 个。
OpenCode学习笔记
这篇先作为 OpenCode 的长期学习笔记，不急着写成完整教程。后面关于 OpenCode 的配置、踩坑、Agent 设计、Skill 复用，都放在这里。
解读 Codex-maxxing for long-running work
最近看了一份 OpenAI 的白皮书，标题是 Codex-maxxing for long-running work。一开始我以为它会讲很多具体技巧，比如怎么写 prompt、怎么开线程、怎么安排自动化。但读完之后发现，它真正想讲的不是某个功能，而是一个更大的变化：
Loop Engineering
前阵子在 Ziron 里跑服务端 packet 切片迁移，我把整个流程拆成了一个可以自己循环的系统：每一轮提取一个 packet 组，写 fixture、跑兼容性测试、更新文档、提交、合并，然后读 STATUS.md 里写好的下一个任务，继续下一轮。这就是后来被叫做 Loop Engineering
如何设计项目AI改造Skill
最近在 AgentInfra 里做了一个新的 Skill，名字叫 harness-builder。
如何沉淀Skill
我建议你们内部不要只分成“两类”，而是分成下面四类。这样后续盘点项目资产时会清楚很多。
AI趋势追踪-我们的岗位还能活多久
最近几个月我一直在盯几件跟 AI 有关的事：Claude 的发布节奏、几篇讨论 PM 和开发者岗位会被怎么洗牌的文章、还有 Vibe Design 这类新提法。单独看每一条都像是新闻，但放在一起的时候，它们其实在回答同一个问题——我们这些写代码、做产品的人，岗位还能活多久。
OpenClaw背后的哲学
不夸张地说，OpenClaw 这波热，不是因为它“又是一个更强的聊天机器人”，而是因为它第一次让很多人真切感受到：AI 开始从“回答问题”变成“替你操作世界”。官方把它定义为“运行在你自己设备上的个人 AI 助手”，可以接入你已经在用的沟通渠道；而媒体和官方评论对它的描述也高度一致：它不只是能说，还
Agent技术选型分析
Agent 框架选型不能只看谁最火。真正要先问的是：流程有没有分支和重试，任务会不会跑很久，状态要不要恢复，工具和人类审批是不是链路的一部分。
从harness看未来软件工程师的工作职责
我现在更确定的一点是：AI 写得快，不等于系统交付得快。工程师的价值不会只剩“亲手敲代码”，但也不会自动消失，它会更多落在问题定义、执行环境、反馈回路和结果验证上。
OpenClaw学习笔记
如果我希望 OpenClaw 单独开一个受管浏览器，而不是复用当前 Chrome：
程序环境下代理不生效的问题
在开发 DeepListener 时，我们遇到了一个极其困扰的问题：
weekly-summary-20260125
这个想法部分正确。但随着时间的推移，我越来越意识到，真正成功的工程师不一定是最优秀的程序员，而是懂得驾驭代码之外一切的人。
Prompt-ScrollTelling
网页内容： 1、滚动叙事网页内的文案 2、滚动叙事网页内的图像 3、文案和画面风格、交互参考纽约时报或南华早报网站中叙事可视化内容
weekly-summary-20260111
这在经济学上称为"不对称收益"（asymmetric returns），就是风险和收益不对称。失败的可能性很大，但只会损失一小笔钱，成功的可能性很小，但是一旦成功，就会获得巨大收益，简单说就是"小亏大赚"。
技术拆解-ChatCut
ChatCut 值得关注的地方，不是“AI 自动剪视频”这个口号，而是它把视频素材先变成可检索、可推理的语义索引。剪辑的核心动作也就从拖时间轴，变成了找素材、组织叙事和生成可编辑的片段序列。
AG-UI
AG-UI 对我最大的启发，不是又多了一个协议名，而是它把 Agent 和前端 UI 之间的边界讲清楚了：模型怎么想是一层，工具怎么调是一层，运行过程怎么让用户看见、确认和接管，又是另一层。
研究员的工作范畴
👉 研究员不是只想 idea，而是要能设计实验或原型验证
可视化能力构建
第一部分是关于组件能力。我们提供了许多可视化组件，主要落地在公司to B和to C的业务中。业务方通常在我们的平台上进行一站式的可视化配置，完成后以代码形式将这些组件应用到他们的项目中。此外，我们对这些组件进行了上层封装，提供不同主题以适配各业务线，比如海外业务线、首长的业务线、资讯业务线等；同时也
英语语法中的常见概念
请帮我梳理下，并对这些概念进行合理的分类、说明（包括其英文名称是什么，为什么要叫这个中英文名字)、举例等，方便我快速理解、学习、彻底掌握和应用这些内容。
美国学生如何学习英语
美国学生的英语学习方式，和很多非英语国家的“英语课”非常不同，因为：
什么是Agentic AI
Agentic AI（代理型AI，或译作智能体AI）代表了人工智能发展的一个新阶段，其核心在于强调 AI 系统的自主性、目标导向和行动能力。
2025年SeeConf参会记录
5 年前，偏右在做 Ant Design，现在他在探索 AI 工程和前端的职责边界。他将在 SEE Conf 2025 分享《AI for Frontend》。
Debug-HXKLine在低端机型卡死
如何避免上来就钻入细节，这里有2个技巧： - 先逮着问题反馈方，问10个问题 - 自己反复使用和测试出问题的页面，详见下一个章节 ### 没有明确现象和问题的范围域 >排查问题和架构设计一样，都应该遵循这个原则：自顶向下，逐步求精。
模板-ECharts业务配置
请从当前项目代码中，抽取可复用的工具函数，加入这个模板代码（visualization-framework）的合适位置中去
ECharts配置的范式演进-从对象规约到意图驱动的系统性方法论
这篇不是抱怨 ECharts 配置项太多。真正的问题是，series、axis、grid、visualMap 这些东西的依赖都藏在一个 JSON 里，复杂图表一多，就像在维护一份隐式场景图。
如何突破前端发展的困境
前端不会突然消失，但只会堆页面、追框架的人会越来越被动。更现实的出路，是把业务问题往架构、组件、工具和可衡量价值上推。
技术拆解-Recharts
这篇最有价值的地方，是用源码证据把 Recharts 的架构讲清楚：它更像一个 Redux 驱动的可组合声明式图表库，而不是一个可以随手套上“微内核”名词的系统。
weekly-summary-20251019
假设你要重构一个大型项目的代码： 1. 1. 第一步：让 Sonnet 4.5 分析整个项目架构，找出问题点，制定重构方案 2. 2. 第二步：让多个 Haiku 4.5 实例并行处理各个模块的具体重构 3. 3. 第三步：再让 Sonnet 4.5 做代码审查 这样一来，复杂的部分由最强的模型把关
可视化业务开发框架解析
一般是把2、3、4提出来做个链接，其目的是为了解决查询、管理问题，提高可维护性，可以理解为是一个微型数据库，算是个cache。
OpenDeepWiki的文档生成策略
OpenDeepWiki 是一个基于 .NET 的智能文档生成平台，采用模块化管道架构，主要组件包括：
基于AI进行项目重构的工作流
最近我在频繁地进行项目的优化重构操作，在这个过程中积累了一些理解项目和分析项目的经验，这里简单地记录一下作为今后的参考。
通过一个项目掌握Agent开发的全部内容
目前，Agent 相关的开发已经成为主流趋势，因此出于多方面考虑，我们必须掌握 Agent 开发的流程以及相关的技术细节。
资讯可视化-如何提升生成内容的质量
目前，我们对 prompt 的依赖程度过高，大部分逻辑都通过 prompt 来实现，这一现状带来了大量的不确定性与稳定性问题。对此，我认为较为合理的改进方向应从两个层面着手： 第一，将部分工作从 prompt 转移到工程化层面，尤其是那些具备确定性的工作，比如一些程序化计算流程的管理等； 第二，对于
AI Coding-2025年8月
用 AI 写代码以后，我最大的感受不是“终于不用学习了”，而是更容易误以为自己已经掌握了。代码能跑出来，只说明模型完成了一次生成；需求有没有讲清楚、边界有没有守住、改动能不能验证，还是人的责任。
资讯可视化-基于沟通日志的AI复盘
同时，请依据这些问题的严重程度、出现频率等维度做出分析排名；在此基础上形成一份总结表格，并将上述所有分析结果写入本地 Markdown 文件。信息越详细越好，不要丢失任何信息。最后，请再反思文档与已分析的问题，确认是否还有可以补充的内容。
MetaPrompt
简而言之：我要的是一个 元 Prompt —— 用来指导 AI 从已有代码中逆向提取出"原始需求 Prompt"。
文档驱动开发
文档驱动开发的核心思想是：No Code - 先用 AI 生成完整的技术文档，再基于文档生成代码。这种方法论源于我在实际项目中的探索和思考。
资讯可视化流程分析
这篇想解决的是一个很具体的阅读问题：用户读资讯时，遇到数字、公司、术语和事件线索，经常要跳出去查。我的方案不是另做一个大而全的 Agent，而是把文章拆成可追踪的 chunk，再把解释、图表和时间线嵌回原文附近。
近期关于AI Coding的感想
最近这段时间，我几乎每天都在和各种 AI 编程工具打交道。这个过程有点像是在玩一场大型的"抽卡游戏"，有时候你会抽到 SSR，有时候则是连续的 R 卡。
如何设计一个前端组件库
这篇不是在说“封装几个组件”。我真正想拆的是：一个可视化组件库怎么跨框架使用，怎么同时支持 CDN 和 npm，怎么按需加载，组件销毁时怎么把事件、动画和资源清理干净。
近期的学习和工作流
这段时间最大的收获是形成了「早上听 -> DeepResearch 调研 -> 生成可视化网页巩固理解」这条信息获取闭环，以及用多窗口并行写代码来压榨 AI Coding 的效率。代价是同时处理太多线索容易被【打断】后失忆，所以提前一天梳理第二天的工作、保持单一时间线，比单纯堆窗口更重要。
技术拆解-LangExtract
LangExtract 是由 Google 开发的一个 Python 库，专门用于使用大型语言模型（LLMs）从非结构化文本中提取结构化信息。该项目提供了一个完整的信息抽取流水线，具有高度的准确性和可扩展性。
Chrome插件开发技术选型
在过去的几周里，我和我的团队深度参与了一个 Chrome 插件开发项目，从最初的技术选型到最终的 POC 验证，踩了不少坑，也积累了一些经验。今天我想把这些经验分享给正在考虑 Chrome 插件开发的你。
技术拆解-CozeStudio
Coze Studio 最值得看的不是“低代码 Agent 平台”这个标签，而是它怎么把模型、工作流、插件、知识库、数据库和发布管理放到一个工程系统里。它的问题也很典型：Agent 产品一旦从 demo 走向平台，就不只是 prompt 和工具调用，而是领域模型、资源管理、运行时、权限和运维一起上桌
更安全的解析function字符串
在开发基于 AI 的 ECharts 配置修改器时，我遇到一个问题：当 AI 返回包含 JavaScript 函数的图表配置时，这些函数在传输和解析过程中丢失，导致动态配置（如颜色函数、格式化器等）无法正常工作。 关联内容：[[流式输出]]
weekly-summary-20250720
F10的技术选型： https://fellou.ai/eko/docs/getting-started/eko/
Gemini CLI 使用技巧
这篇是我用 Gemini CLI 一段时间之后攒下的技巧和踩坑记录。不是文档搬运——官方文档能查到的我就不重复了——重点是那些实际用起来才发现的点：什么场景它好用、什么场景它会让你抓狂、以及跟 Claude Code 比起来各自的定位。
weekly-summary-20250705
文档转PPT https://stackblitz.com/github/slidevjs/new?file=slides.md 帮我基于 /Users/leozhou/git/VISALL/docs/refactor/MCP 下的内容，用 Slidev 这个专门用来用 Markdown 格式生成
Vibe Coding Experience Summary
Recently, in my development work, I have extensively used Vibe Coding, continuously engaging in a demand-feedback-correction cycle with AI IDEs. Durin
Vibe Coding经验总结
最近在开发工作中，我大量使用了 Vibe Coding，不断与 AI IDE 进行需求-反馈-修正的循环交互。在这个过程中，我一直在思考如何能够将 Vibe Coding 的效果发挥到最大。我认为最关键的是需要整理出一套方法论，解决以下两个核心问题：
Gemini CLI 源码分析
不过目前使用起来，感觉还不达成熟。不过因为是开源的，估计过一段时间会好很多，可以当成一个储备的工具先关注着。 目前的重点，还是借助其源码，学习一下AI CLI的实现思路。
weekly-summary-20250615
最酷的是，这打破了技术壁垒。比如，Claude Code 是用 TypeScript 写的，但我们公司大部分项目用的是 Python。昨天我在 Slack 上看到一个同事，他不懂 TypeScript，但他想修复 Claude Code 的一个问题。于是他直接和 Claude 对话，一个小时内就生成
可视化图表生成MCP
这篇不是在讨论“再做一个图表生成器”，而是在记录一件更实际的事：已有图表能力怎么变成 AI 可以稳定调用的工具。我的判断是，先把成熟 case、schema 和渲染出口整理好，比从零开始训练一个“会画图”的模型更靠谱。
weekly-summary-20250406
灵活适配的模型选择 得益于多 Agent 架构，我们可以根据任务的复杂度和模型的特点，灵活选择最适合的模型。例如，对于数据拆分这类相对简单的任务，7B 小模型即可快速输出结果，确保高效执行；而对于更复杂的任务，则可以选择更强大的模型来保证输出质量。
阅后即焚类型的可视化
解决<font color="#ff0000">长尾</font>可视化需求、<font color="#ff0000">一次性</font>需求。 目前AIGC暂时不能解决复杂可视化问题，就先解决简单可视化问题。 展平式的SVG + Claude ## 适用场景 不同的方向，产品规划和技术路线是
weekly-summary-20250323
这周我的睡眠时间严重不足，每天基本只睡了6个多小时，但令人惊讶的是，我整体精神状态却非常好。白天也不犯困，这主要归功于我感觉正在做的事情对我而言非常有意义——每天都在花时间准备系统架构设计师的考试。
weekly-summary-20250105
论文： https://github.com/deepseek-ai/DeepSeek-V3/blob/main/DeepSeekV3.pdf 论文中，明确提出了 DeepSeek-V3 仅使用 2048 块 GPU 训练了 2 个月，并且只花费了 557.6 万美金。
LLM开发经验
LLM 适合做的两种事情：抉择+多样性(比如：生成搞笑的风格)。
AI项目开发总结-叙事可视化
比如动画类型。 之前东明的可视化推荐也是这个问题，搞了很多图表，但是场景无法命中。
weekly-summary-20241110
Manim：命令式(怎么做) ZRender：声明式(做什么)
可视化开发和前端开发的区别
更注重抽象(Core)与扩展性(让业务方可以基于我们提供的 Core 机制，快速扩展自己的个性化需求)
weekly-summary-20240915
单元测试用于验证正确性，Self-play 用于尝试和学习，两者结合，可以实现 AI 可视化配置！ UI 稿/截图-LLM 试错-单元测试验证-LLM 试错-单元测试验证...... 将可视化配置任务转换成一个类似围棋的自我对弈任务，通过强化学习解决。 这个是一个很好的思路，可以尝试一下，有搞头！
Weekly Summary(20240714)
https://www.zhihu.com/question/660384108/answer/3551179520
可视化技术架构升级
现在处于类似jQuery和三大框架之间的那个框架层出不穷的阶段，后面会有一个或者几个牛逼的技术框架来统一整个开发领域，Agent可能会是一个选项。
关于AI产品的关键因素的思考
这一年，公司在全力推动 AIGC 产品。似乎每个部门都在做，但是真正成功的产品几近于零。
AI浪潮下开发模式的变革
AI 浪潮正在改变软件开发模式，为开发者带来新的机遇和挑战。本文通过实际工作案例讲述了 AI 对个人开发工作的影响，以及 AI 时代下产品开发模式的变革，并分析了大模型时代程序员与 AI 工具的定位，希望能帮助开发人员提前布局，抓住新一轮发展机遇。
技术拆解-贪吃蛇
self.bordersize = 20 self.displaywidth = self.width + 2 self.bordersize self.displayheight = self.height + 2 self.bordersize + 40
LLM学习笔记
大语言模型（Large Language Models）能够解决的核心问题是自然语言处理中的文本生成和预测。具体来说，其目标是建立一个对给定输入序列概率进行建模的模型，利用该模型来生成具有自然流畅性和连贯性的文本，包括自动摘要、机器翻译、聊天机器人、问答系统等。
ChatGPT模板
three.js,babylon.js,Cocos3D,Oasis Engine,Unity,Unreal Engine
按键精灵学习笔记
按键精灵可以使用各种标准VBS命令，比如数值操作、字符串操作等