从可编程到表现力:构建更好的 Agent 运行时重塑用户体验
最近,我重新看了 remio 在 PPT DSL 上的尝试,也注意到 OpenAI 的 **Artifact Tool**(产物工具)正逐渐演进成一套完整的专业文档运行时。
Blog
最近,我重新看了 remio 在 PPT DSL 上的尝试,也注意到 OpenAI 的 **Artifact Tool**(产物工具)正逐渐演进成一套完整的专业文档运行时。
最近,我们一直在尝试优化 Better Harness 的 **SKILL 自动沉淀**能力:从 Agent 的真实会话中识别重复出现的工作路径,再判断其中哪些经验值得进一步沉淀成可复用的 SKILL。真正做起来以后,我们发现这件事远比“把一段 Session 分析一遍”复杂得多。
把一项能力写进 `SKILL.md`,再封装成 Agent 插件,并不难。真正困难的是,当它被不同用户、不同项目和不同 Agent
最近我重新整理 [Better Harness](https://github.com/QoderAI/better-harness) 的 `references`
过去几年,我们讨论 AI 对软件研发的影响,最常使用的仍是个人生产力:一个功能要多久,一名开发者能同时推进多少任务,Coding Agent 能生成多少代码。AI 确实显著降低了执行成本,过去数天才能形成的初步实现,现在几个小时后就可能进入 Pull Request。
Piece 尝试把编码智能体的局部代码修改映射为片段级构建反馈,让文件内部的函数、组件、接口和 JSX 结构成为可追踪、可验证、可回退的反馈单位。
上周买了一个带触发屏的开发板,想探索一下之前的一个想法:AI 时代能不能加速传统行业的一些软件开发的范式?作为一个写过物联网书籍的“资深”硬件专家,
周末,我使用 Claude Code 的 `/workflows` 做了两个实验,结合我使用 Codex `/goal` 做的一系列实验,把两个能力放在一起看,
周末,我又凭感觉写了一个小想法:用 Swift 写一个 PowerPoint 查看器。因为我已经有一个技能可以生成幻灯片、XLSX 和
> 之前 Codex Pet 很火,我也想在 Qoder 里放一个类似的小东西。于是,周末 Vibe Coding 了一把。做着做着才发现,它要解决的好像不是“再多一个 Notification”。
我还没从 Thoughtworks 离职的时候(现在在 Qoder 团队),我就想写一篇文章,把一张图里 `Loop` 那一栏补完整。那张图其实很直白:不是让 AI 生成更多代码,而是让 AI 在工程体系中稳定完成交付。左边是 `Rules`,把团队经验和开发约束变成 AI 可执行的工作规则;中间是 `Spec`,把模糊需求收敛成可拆解、可验证、可追踪的交付目标;右边是 `Harness`,把 AI 行为纳入工程治理边界,确保结果可验证、可度量、可放行。
在 Thoughtworks(现 Inspire) 的最后一个月里,我一直在为“下一个项目”准备一套 AI Coding 的端到端方案。这个方案基于 Claude
在时时使用多个 Codex/Copilot/Claude/Qoder 编写代码之后,我第一次明显感觉到,整个产品推进的节奏都被拉快了。
几个月前,当 Coding Agent 的 CLI
TL;DR:[https://github.com/phodal/routa](https://github.com/phodal/routa),Harness Monitor 在 `crates/harness-monitor` 目录下。
今天下午,我在 Routa 的看板里点开一张已经进 Done 的卡:[Sub-issue] 为 GATE-first 专家提示注入单次 trace 状态摘要。
最近这段时间里,我做了一件比“让 AI 帮我写文章”更麻烦的事:不是继续打磨 Prompt,而是先让它系统分析我过去十年的文章,再把这些分析结果整理成一个可以被反复加载的写作
过去大半年里,我一直在帮不同规模的团队落地 AI Coding。从最早的一两个人试点,到十几个人的团队尝试让 AI
在最新的 Routa Desktop 中,我们引入了 Harness 工程可视化系统。它并不是一个展示“AI 写了多少代码”的界面,也不是为了给生成式开发增加一层炫目的仪表盘,
当 AI 开始真正参与软件交付时,团队面对的核心问题已经悄悄变化了。过去我们关心的是代码写得够不够快、自动化够不够多,而现在,越来越多团队首先要回答的是另一个问题:当生成速度不断提高之后,系统靠什么抵抗持续上升的代码熵。