xiaohack's Blog - 代码补全
type: channel
link: https://blog.xiaohack.org/tag/bbbe935b-c5eb1e/
items: 从「代码补全」到「全托管 Agent」：我的 2025 AI Coding 进化论
items: 别只盯着补全：2026 具备“独立思考”能力的免费 AI 编程助手排行
items: 把你的需求告诉我，我来免费帮你实现！
items: 了解你的 AI 编码伙伴：Coding Agent核心机制解析
items: 复刻 continue，实现行内补全功能 autocompletion

从「代码补全」到「全托管 Agent」：我的 2025 AI Coding 进化论
type: item
date: 2026-01-27T16:11:16+08:00
description: Matrix 首页推荐Matrix 是少数派的写作社区，我们主张分享真实的产品体验，有实用价值的经验与思考。我们会不定期挑选 Matrix 最优质的文章，展示来自用户的最真实的体验和观点。文章代表作者个人观点，少数派仅对标题和排版略作修改。2025 年，我的工作习惯彻底被 Claude Code、Cursor 和 Codex 改变了，它们给我带来的改变，不亚于当年我用易语言写出第一个应用程序。同时这句话不仅适用于我的产品经理身份，也同样适用于我的工程师身份。对我来说这不仅是软件开发效率的提升，也是软件开发方式的重构。我说的是哪种 AI Coding在社交媒体上讨论 AI 编程时，很多时候大家其实没有对齐在讨论的 AI 编程范畴和适用领域。所以大部分情况下大家在鸡同鸭讲，公说公有理、婆说婆有理。在我们真正讨论 AI 编程之前自然需要先澄清一下，我们到底在讨论什么「AI Coding」？目前来说， AI Coding 有几种不同的产品和用户交互形态，包括：L1：古典的 ChatGPT 交互问答。有问题直接问 ChatGPT、Gemini、Claude 等 AI 助手，借助 AI 助手给出的信息，自行 Debug 和修改代码。L2：IDE / 插件中提供的补全功能。直接写函数名，然后 AI 会帮你补全函数的细节，你再自己微调或者不微调。这种能力其实过去也有，只是没有这么强悍。大家使用 IDE 来开发，很大程度上就是在利用 IDE 极佳的补全能力。L3：本地 AI Coding 工具的 Agent 模式，全托管或半托管式编程。你只描述需要做什么，具体做动作由 AI 来完成；这里还有几个细分的方式，包括完全托管（比如 Claude Code 开 –dangerously-skip-permissions、Codex 开 –dangerously-bypass-approvals-and-sandbox）和半托管（用户手动确认行为，只是由 AI 来完成具体修改的动作）。L3 操作的是你的本地环境，有破坏的风险，但也有无限的可能。L4：使用网页端的 AI Coding 工具直接出 Demo。不需要在本地配置任何开发环境，直接在网页端完成 Coding，你只需要描述你想要的东西，剩下的完全交给 AI（虽然这往往意味着难以与复杂的本地业务流集成）。所以大家在社交媒体上和别人讨论 AI Coding 的时候，很有可能你在聊 L3、但别人在聊 L4。看似聊的是一个东西实际上完全不同。我们这篇文章讨论的则主要是 L3 —— 即使用本地的 AI Coding 工具的 Agent 模式，全托管或半托管式编程。为什么是 Agent 模式说完了大家眼中不同的 AI Coding 工具，我也必须再强调一下，即使大家聊的都是「AI Coding 工具的 Agent 模式」，因为身份不同，每个人的用法也会有很大差异，大家对工具的预期也完全不同。因此对 Agent 模式的评价大体也可以拆分为三个大类：传统的软件工程师：使用 AI Coding 工具完成自己工作过程中的一些辅助性工作，对于自身的能力和工作的要求有较高的要求。有一定研发概念的产品工程师（称之为产品工程师是因为他们有一些基础的软件工程概念）：使用 AI Coding 工具拓展自己的能力圈，去做一些之前必须依赖软件工程师才能做完的事情（比如做个小 Demo，或是上线一个软件产品）。被媒体上的文章忽悠进来的小白（他们基本上没有太多的软件工程经验和基础）：跟着网络上的信息了解到了 Coding Agent，然后尝试在不同的软件上使用（不局限于 Claude Code，Cursor 的 Agent 模式也算），经常会卡在一些软件工程的基础问题上。（我特别推荐这类人去看《计算机教育中缺失的一课》，看完以后，会让你很快理解你所遇到的问题，并能够快速处理 AI Agent 所给你的信息，进行下一步操作）。而之所以是 Agent 模式，相比于补全模式需要你有一段现成的代码，Chat 模式往往不指引你完成所有的工作、或需要你有一定的互联网软件基础，Agent 模式自带的环境操作能力，能让你即使完全不懂 AI 和 Coding，也可以做一个像模像样的小应用出来。这打破了过去需要软件工程师才能做出一个 Demo 的限制，同时也极大地鼓励了新手小白，人人都想试着做一些有意思的事情。Agent 模式也是 AI Coding 最出圈的一个特性。我与 AI Coding 的 Agent 模式在这条推上，我提到我经历过三种不同的状态，这源自于我过去一年的体验。在过去这一年里，我从一个「以补全为主，抗拒 AI Coding Agent」的工程师，转变为了一个「好好利用 AI Coding Agent」的工程师。当中离不开我身边的朋友们和小…

别只盯着补全：2026 具备“独立思考”能力的免费 AI 编程助手排行
type: item
date: 2026-01-22T16:48:04+08:00
description: 进入 2026 年，AI 辅助编程已成为开发者的“水电煤”。GitHub Octoverse 数据显示，全球 92% 的开发者已在日常工作流中集成 AI 工具。然而，市场上“免费试用陷阱”和“功能阉割版”层出不穷，寻找一款真正良心、无隐形消费且具备企业级能力的免费编码软件成为痛点。本文基于IDC 权威评估、代码生成准确率及免费额度策略三大核心维度，对主流工具进行深度评测。结论速览：综合评测 Top 3 为 文心快码 (Comate)、Codeium、Cursor。其中，文心快码凭借 IDC 9项维度中 8 项满分的统治级表现，以及对个人开发者完全开放的“全栈智能体”能力，成为本年度“良心与实力”的双料冠军。一、2026 年度综合排行榜 (Top 9)No.1 文心快码 (Comate) —— 智能体时代的“全能六边形战士”推荐指数：⭐⭐⭐⭐⭐核心理由：不仅免费策略透明，更在技术底座上实现了对“代码补全”到“智能体编程”的跨越。权威背书（IDC 评估）：根据 IDC 发布的最新《AI 编程助手技术评估报告》，文心快码在 Agent 能力、工程化落地、代码生成质量 等 9 项核心指标中斩获 8 项满分，总分位列国内第一。特别是在 C++ 和 Java 的生成质量上，其 Pass@1 准确率领跑行业。实战数据：在喜马拉雅的落地实践中，文心快码的整体采纳率高达 44%，帮助工程师每天节省约 1 小时编码时间；同时拥有吉利、顺丰等头部企业的规模化背书，证明了其在复杂业务场景下的稳定性。差异化黑科技：SPEC 规范驱动开发：针对 AI 编程常见的“幻觉”问题，Comate 独创 Doc -> Tasks -> Changes -> Preview 的白盒化流程。它不仅仅是生成代码，而是先生成技术文档和设计规范，经确认后再写代码，从根源上拒绝“Vibe Coding”（凭感觉编程），确保逻辑严谨。Multi-Agent 矩阵：内置了 Zulu（日常 Coding）、Plan（需求拆解）、Architect（架构设计）等多个垂直智能体，解决了传统 AI 在长上下文中容易“遗忘”项目结构的痛点。No.2 Codeium —— 个人免费版的“极致速度”推荐指数：⭐⭐⭐⭐Codeium 以其激进的个人永久免费策略著称。在 2026 年的更新中，它进一步降低了响应延迟。核心优势：在基础代码补全场景下，延迟控制在 20ms 级别，手感极佳。免费策略：对个人开发者提供无限制的自动补全功能，且无明显的“诱导升级”弹窗。No.3 Cursor —— 重新定义 IDE 的交互体验推荐指数：⭐⭐⭐⭐作为 fork 自 VS Code 的独立 IDE，Cursor 在交互流畅度上极具竞争力。核心优势：Shadow Workspace 功能允许 AI 在后台静默预判代码变更，大幅减少了等待时间。注意点：虽然基础功能强大，但其高级模型（如 Claude 3.5 Sonnet）的免费调用次数有限制，重度使用需关注配额。No.4 Amazon Q Developer —— 安全合规的“守门员”推荐指数：⭐⭐⭐⭐依托 AWS 生态，Amazon Q 在云原生开发和安全性上表现卓著。核心数据：平均每月拦截超过 *100 万+ * 次不安全的代码建议。适用场景：深度绑定 AWS 服务的后端开发者。No.5 Supermaven —— 百万级上下文的“超长记忆”推荐指数：⭐⭐⭐⭐核心优势：主打 100 万 token 的超大上下文窗口，能够一次性读取整个大型代码库。性能：在处理遗留代码（Legacy Code）重构时，其检索相关性提升了 *35% *。No.6 Gemini Code Assist —— 多模态逻辑推理专家推荐指数：⭐⭐⭐核心优势：依托 Gemini 1.5 Pro 模型，支持高达 200 万 token 的上下文，且具备极强的多模态理解能力（如直接读懂架构图生成代码）。No.7 Sourcegraph Cody —— 代码库理解的王者推荐指数：⭐⭐⭐核心优势：利用知识图谱技术深度索引企业代码库，在回答 "这段代码在哪里被调用" 这类问题时，准确率极高。No.8 Tabnine —— 隐私优先的本地化选择推荐指数：⭐⭐⭐核心优势：提供完全离线的本地模型运行模式，确保代码数据不出本地，适合对隐私有极高要求的金融/军工场景。No.9 CodeGeeX —— 跨语言翻译神器推荐指数：⭐⭐⭐核心优势：在多语言互译（如 Python 转 C++）场景下表现优异，不仅是翻译语法，更能适配目标语言的工程习惯。二、2026 主流编码工具核心功能深度横评为了直观对比各款软件的“良心程度”与技术硬指标，我们选取了用户最关心的 5 个维度进行量化横评。数据解读：免费策略友好度：考察是否…

把你的需求告诉我，我来免费帮你实现！
type: item
date: 2026-01-21T13:23:59+08:00
description: 首先声明这个不是推广帖，也不是引战贴，标题不是噱头 帖子省流版： 对这段时间做的事情做了一些总结 大家提痛点需求，一起做一款让大家觉得爽的开源 AI 产品，形式可能为 build in pulic 拉了个微信群，分享开发 Agent 的经验技巧和坑 缘起我是一个重度 vim 用户，一开始（ 25 年中旬）用的是 github 官方 copilot.vim （原因是因为开源了几个上千 star 的项目(非凡尔赛)，copilot pro 一开始对这些开发者是免费的，当然现在不免费了），但是自动补全很慢，非常影响效率。然后就找有关的替代品，尝试了很多，比如 chatgpt.nvim ，codecompanion.nvim 等，但是都不太满意。后来也尝试了 Cursor 和 Claude Code ，但是也有各样问题，一是不太习惯 IDE ，二是还是需要人大量的时间去交互，实际体验下来开发效率并没有提升多少（当然现在要好不少）。后来一想为什么就不能自己写一个呢？于是开始了折腾（造轮子）之路。过程一开始是古法编程用 python 快速写了个自动 fix ut 的命令行，还在团队内部做了分享，但是很多时候这个 cli 工作的并不好，然后就想办法优化。看了很多资料，差不多 100+篇关于 AI 的论文（在 alphaxiv 的帮助下，挑重点 paper 细读。主题包括框架、Agent/Multi-Agent 、注意力、记忆、规划等等），其中一篇给我比较多启发的是 Alita 这篇论文 https://arxiv.org/abs/2505.20286 。当时 Context Engineering 这个概念刚火，还花了好几天看这个 https://github.com/davidkimai/Context-Engineering （后来证明这个项目对我来说基本没用）。然后设计出一套方案，目标是做一个让自己用起来爽的 Agent ，具体来说是： 快（干活快） 狠（彻底解决问题） 准（交付质量高） 美（产品要有设计品味） 充分发挥不同大模型的能力，不局限于单一模型。下面是一开始的架构设计：集中精力花了差不多 3 个月时间实现，中间还重构了一版（因为效果没有达到预期），核心逻辑全部手写，其他部分前期使用了 Cursor 来帮助写 TUI ，后面就全是用产品自己开发自己了。产品产品形态是 Desktop + Tui ，可以编程、Research 、干杂活等，可以简单理解为 Claude Code + Cowork 。 桌面版 对应视频在这 TUI 对应视频在这问题上个月底这个月初找了几个朋友内测了下，大家给了一些建议。这两天也开源了，在 HN 和 v2 也分别发了一个帖子简单介绍了下，反馈都比较平平，发的帖子很快沉下去了。我自己反思了下，可能是自己做的东西确实不够好，也可能是大家没关注到，或者大家关注到了但是不感兴趣。所以想看下大家真实的想法，先抛个几个问题： 现在大家对此类工具和产品怎么看？是产品引不起自己的兴趣吗？ 除了 claude code/codex/cursor/opencode 等，还用其他什么比较好的产品吗？比如豆包 现有的工具已经能很好的解决自己的问题了吗？还有其他的痛点吗？ 最后大家需要的话，我可以免费帮实现大家实现有关功能，未来产品的形态由大家来定义。另外我拉了个微信群，准备把开发 Agent 的时候一些经验技巧和坑分享一下，同时也方便大家交流有关话题，有感兴趣的可以评论区留言我拉一下大家进群。

了解你的 AI 编码伙伴：Coding Agent核心机制解析
type: item
date: 2026-01-21T10:17:06+08:00
description: 导读AI 编码工具正在从"智能补全"演进为能自主完成复杂任务的 Coding Agent。本文基于开源项目源码研究与实践经验，系统性地拆解 Coding Agent 的工作原理。旨在帮助开发者在了解Coding Agent后，与AI伙伴更好的协作配合，更高效的提问和拿到有效结果。01 背景AI 编码工具的发展速度快得有点"离谱"。从开始使用 GitHub Copilot 的代码补全，到使用Claude Code、Cursor、Comate IDE等完成复杂编程任务，AI 不再只是个「智能补全工具」，它能读懂你的代码库、执行终端命令、甚至帮你调试问题，成为你的“编码伙伴”。我自己在团队里推 AI 编码工具的时候，发现一个很有意思的现象：大家都在用，但很少有人真正理解它是怎么工作的。有人觉得它"很神奇"，有人吐槽它"经常乱来"，还有人担心"会不会把代码搞乱"。这些困惑的背后,其实都指向同一个问题：我们对这个"伙伴"还不够了解。就像你不会无脑信任一个新来的同事一样，要和 AI 编码伙伴配合好，你得知道它的工作方式、能力边界、以及怎么"沟通"才更有效。在经过多次的实践尝试后，我尝试探索它的底层原理，并写下了这篇文章记录，主要围绕了这些内容展开：Coding Agent 的核心工作机制，包括身份定义、工具调用、环境感知等基础组成。从零实现一个最小化 Coding Agent 的完整过程，以建立对 Agent 工作流程的直观理解。上下文管理、成本控制、冲突管控等生产环境中的关键技术问题及其解决方案。Rule、MCP、Skill 等能力扩展机制的原理与应用场景。在了解原理后，我和伙伴的协作更佳顺畅，让伙伴更清晰的了解我的意图，我拿到有效的回答。02 概念2.1 从Workflow到Agent取一个实际的例子：休假申请。如果我们的需求非常简单：一键申请明天的休假。这个需求可以被简化为一个固定的工作流：打开网页。填写起始时间。填写结束时间。填写休假原因。提交表单。全过程没有任何模糊的输入，使用程序化即可完成，是最原始的工作流形态。如果需求再模糊一些：申请后天开始3天休假。这个需求的特点是没有明确的起始和截止时间，需要从语义上分析出来：起始时间：后天。休假时长：3天。转换日期：10.14 - 10.16。执行申请：提交表单。这是一个工作流中使用大模型提取部分参数的典型案例，是模型与工作流的结合。如果需求更加模糊：国庆后休假连上下个周末。这样的需求几乎没有任何直接确定日期的信息，同时由于年份、休假安排等动态因素，大模型不具备直接提取参数的能力。将它进一步分解，需要一个动态决策、逐步分析的过程：知道当前年份。知道对应年份的国庆休假和调休安排。知道国庆后第一天是星期几。国庆后第一天到下个周末设为休假日期。额外补充调休的日期。填写并提交表单。可以看出来，其中1-5步都是用来最终确定休假日期的，且需要外部信息输入，单独的大模型无法直接完成工作。这是一个典型的Agent流程，通过大模型的智能与工具访问外部信息结合实现用户需求。2.2 什么是AgentAgent是以大模型为核心，为满足用户的需求，使用一个或多个工具，自动进行多轮模型推理，最终得到结果的工作机制。2.3 什么是Coding Agent在Agent的基本定义的基础上，通过提示词、上下文、工具等元素强化“编码”这一目的，所制作的特化的Agent即为Coding Agent。Coding Agent的最大特征是在工具的选取上，模拟工程师进行代码编写的环境，提供一套完整的编码能力，包括：阅读和查询代码：读取文件，对应 cat 命令。查看目录结构，对应 tree 命令。通配符查找，对应 ls命令（如 **/*.test.ts 、src/components/**/use*.ts）。正则查找，对应grep 命令（如function print\(.+\) 可以找函数定义）。LSP（Language Server Protocol），用于提供查找定义、查找引用、检查代码错误等能力。编写或修改代码：写入文件。局部编辑文件。删除文件。执行或交互命令：执行终端命令。查看终端命令stdout输出。向终端命令stdin 输入内容。除此之外，通常Coding Agent还具备一些强化效果而设定的工具，通常表现为与Agent自身或外部环境进行交互，例如经常能见到的TODO、MCP、Subagent等等。03 内部组成3.1 上下文结构3.2 身份定义一个Agent首先会将模型定义成一个具体的身份（红色与橙色部分），例如在社区里常见的这样的说法：You are a Senior Front-End Developer and an Expert in React, Nexts, JavaScript, TypeScript,…

复刻 continue，实现行内补全功能 autocompletion
type: item
date: 2026-01-01T15:46:55+08:00
description: 行内补全：实现思路与关键细节（FIM + Diff + 多层过滤）想把 “行内补全” 做得好用，核心不是 “能生成”，而是生成后如何稳定落到光标处：不重复、不乱插、不无限循环、单行 / 多行行为符合预期。先看结论使用标准 FIM（Fill-In-the-Middle） 流程：prefix + suffix -> middle内置模型：Pro/Qwen/Qwen2.5-Coder-7B-Instruct（通过统一的 "FIM" 模型名对外提供）非流式请求拿到完整输出，但内部用 “类流式管道” 逐层过滤（字符级→行级→后处理）单行补全额外做 Diff：自动判断 “插入” 还是 “替换到行尾”，避免括号 / 后缀重复多行补全不做 Diff：直接替换到行尾（更符合用户预期，也省成本）1) 整体架构（从 VSCode 到最终插入）流程上分 6 段：预过滤 → 分类 → 模板 → 调用与过滤 → 后处理 → Diff（单行）InlineCompletionProvider -> 预过滤（跳过不该补全的场景） -> 构建 prefix/suffix（HelperVars） -> 单/多行分类 -> FIM 模板渲染 -> 调用 FIM API（非流式拿完整结果） -> 过滤器管道处理（字符级/行级/后处理） -> 单行：Diff 决定 range；多行：替换到行尾 -> 返回 InlineCompletionItem 2) FIM 请求格式与参数FIM 模板（Qwen 标准）<|fim_prefix|>{prefix}<|fim_suffix|>{suffix}<|fim_middle|> 关键约定API 模型名统一用："FIM"请求方式：非流式（一次性拿完整结果）max_tokens：单行 64、多行 128（策略性限制 “胡乱续写” 概率）3) 预过滤：哪些场景直接不补全目的：便宜地跳过 “补全只会添乱” 的场景，减少无意义请求。常见跳过项：配置文件 / 特殊文件模式未命名空文件多光标（multi-cursor）其它明确不应触发 inline completion 的场景4) 单行 vs 多行：分类策略（决定用户体验）分类逻辑按优先级（越靠前越强）：Intellisense 选中项：强制单行（避免和补全列表打架）单行注释检测：强制单行（注释里多行补全通常噪音大）语言特定规则：按语言做微调默认：允许多行5) 过滤器系统：三层拦截，解决 “能生成但不好用”即使是非流式输出，也可以把 “完整文本” 当成流来处理：逐步截断、跳过、清洗。LLM 完整输出 -> 字符级过滤（stop token / suffix 重复 / 首字符换行） -> 行级过滤（行数限制 / 重复行 / 相似行 / 空注释 / 双换行） -> 后处理（空白、重复上一行、极端重复、去 markdown backticks） -> 最终补全 5.1 字符级过滤（更早、更快止损）典型能力：Stop Token 检测：遇到终止标记立即截断后缀重复检测：避免生成 “补全 + suffix + 继续乱写”首字符换行过滤：不让补全以空行开头（体感很关键）5.2 行级过滤（防循环、防抄下一行）典型能力：行数上限：例如超过 50 行直接停止重复行检测：同一行反复出现（模型陷入循环）就停相似行检测：生成内容与 “光标下一行” 相似度过高就停（防重复已有代码）空注释过滤：只输出 //、# 这种空注释行直接丢弃双换行过滤：控制空行数量，避免 “稀碎的大段空白”5.3 后处理（最终把关）典型规则：空白补全直接拒绝重复上一行（基于 Levenshtein 相似度）直接拒绝极端重复模式（例如 6 行以上重复）拒绝去掉模型偶发输出的 Markdown 代码块标记（```）6) 单行 Diff：解决 “补全重复后缀 / 括号” 的关键问题本质FIM 模型对单行位置常见三种输出：纯插入：只生成新内容重复后缀：把光标后的文本也生成了一遍部分重叠：生成内容与后缀部分重叠如果不处理，最常见的坏体验就是：多一个括号、多一段重复 token。解决方式（单行专用）用 diffWords() 比较：currentText：光标后到行尾的已有内容completion：模型给的最后一行补全然后根据 diff 模式判断：该不该只 “插入”还是要 “替换光标到行尾”（即设置 range）Range 语义（VSCode 行为）range = undefined：在光标处插入range = { start: cursor, end: lineEnd }：先删除光标到行尾，再插入（用于清理重复后缀）7) 多行为什么不做 Diff，而是直接替换到行尾？多行补全的期望更像 “接管后续内容”，而不是 “精确对齐每个 token”。选择 “替换…