张一凡93

0. 问题：为什么"先写代码"的 agent 让人不敢用生产 Codex / OpenCode / Claude Code 这类工具，工作流程是： 痛点集中在最后两步：di...

先说结论 Codex、OpenCode、Claude Code 我越用越觉得它们有个共同的盲区：它们都是"先写代码"的。 你把需求丢进去，模型开始疯狂调工具读文件、写代码、...

一个项目里，代码改动通常有清晰的 Git 历史：谁改了什么、在哪个提交、后来怎么合并。架构决策却常常散落在聊天记录、评审评论和某位同事的记忆里。 几个月后再看一个模块，代码...

我们习惯让 AI 直接回答需求：“加一个导出功能”“把列表改成分页”“重构这块逻辑”。它通常很快就会给出代码。但如果它理解错了需求，或者选错了模块，等问题暴露时，改动可能已...

把需求交给 AI，几分钟后代码就出来了。可真正让人头疼的，往往不是“它能不能写”，而是：它改对地方了吗？有没有重复造轮子？这次修改会不会悄悄改变模块之间的边界？ 项目越大，...

一个项目最危险的时刻，不是编译失败，而是所有人都说“能跑”。 Agent 交付了一个功能。你打开 README，有文档；你打开代码，结构和文档对不上； 你问“为什么这里要这...

以前 review 代码，是看一个人怎么想。 现在 review AI 代码，常常是看一堵墙。 Agent 说“完成了”。你打开 diff：30 个文件，1200 行变化，...

一个很常见的对话： 你只想要一个按钮。 这不是段子，而是 AI 编码里非常典型的一种失控：任务本身不大，但实现过程不断 膨胀，最后变成了一次没人要求过的重构。 更麻烦的是，...

先说一个可能不太受欢迎的观点： 上下文不是越多越好。 很多人用 AI 写代码的方式，是把整个仓库打开，或者让 Agent 自己到处 grep。结果 呢？它确实看到了很多代码...

代码 diff 是给实现者看的，架构 diff 是给决策者看的。 这句话听起来有点绝对，但你可以回想一下 review AI 代码时的体验： 500 行 diff，十几个文...

很多人用 AI 写代码的流程是这样的： 提需求； 等它写完； 打开 diff； 发现它把不该动的地方也动了； 重来。 这个流程最大的问题不是模型不听话，而是范围从一开始就只...

一个很典型的场景：我让 Agent 做一个看起来很小的需求——给取消订单加审计。 它改了十几个文件，测试也过了。我打开 diff，看了二十分钟，最后只确定一件事： 它能跑。...

这篇是实操文。目标很简单：让你在自己的项目里跑通一次完整流程—— Agent 提架构提案 → 校验 → 你审阅 → 批准或拒绝 → Agent 自动继续。 全程大约 20–...

首先让我来讲讲它是怎么做的，以及我在几个关键位置上 做的取舍。 先说结论：Jin 的核心不是“让 AI 更聪明”，而是把提案权和决策权分开。 Agent 可以创建提案、修改...

最近两三年，我几乎每天都在用 AI 写代码。 它确实快。一个下午能做完以前一两天的活，改一个模块、补一组测试、顺手把调用方 一起迁掉，都不在话下。但用久了我发现一个更麻烦的...

没有人知道AI泡沫会不会破裂，更没有人知道它会在哪一年出现拐点。 但历史上任何一次技术革命，都遵...

项目地址：https://github.com/ZYF93/EzLang 过去一个月，我在做一门新的编程语言：EzLang。 它还不是一门成熟语言，也不是可以拿去生产环境替...

先说结论：我花了大概 1 个月，借助 AI 以 Vibecoding 的方式，做了一门新语言，叫 EzLang。 项目地址：https://github.com/ZYF93...

Dragonfly专注于解决基于Kubernetes的云原生环境下大规模镜像与文件分发难题。该项目利用点对点（P2P）技术，提供高效、稳定且安全的数据分发与加速能力。...

先说结论，免得大家看半天： 如果你做的是普通后台、普通配置页、普通业务表单，Zustand 很香。 但如果你做的是： AI 聊天界面 Agent 工作台 工具调用面板 检索...