AI编程
-
当 MCP 成为攻击入口:一次可复现的 AI 工具链安全实验
MCP 工具链的风险并不只在单个工具,而在工具、数据与外部通道的组合。开源项目 Aggrete 用确定性规则演示了如何拦截提示注入、工具投毒和 rug pull 三类典型攻击。
-
AI 编程代理因“合并率”导向与开源维护机制冲突,仓库需要重写 AI PR 规则
matplotlib 的一次 AI 代理 PR 争议,暴露出 AI 编程代理在开源协作中的激励错位:当系统只奖励代码合并,维护者就可能被视为需要克服的障碍。
-
AI 编程工具链正在形成新分工:LSP、MCP、ACP 各自解决什么问题
LSP、MCP、ACP 正在成为 AI 编程基础设施中的三条重要协议线。它们分别对应代码理解、模型工具调用和智能体协作,共同构成下一代开发工具通信标准的基础框架。
-
LLM“打字机效果”背后:用 Node.js 与 SSE 实现流式输出
从 Node.js 手写 SSE 服务到 LLM API 的 stream: true,本文拆解大模型“打字机效果”背后的工程实现。
-
给代码智能体加一件“新装备”:从零扩展 Code Agent 工具的完整路径
在 Code Agent 的工程实践中,模型本身并不直接“做事”。它通过 Function Calling 选择工具,再由框架执行并返回结果。因此,扩展一个代码智能体,往往不是重新训练模型,而是给它增加新的工具。
-
AI编程助手频繁“断片”?Cursor、Lovable、Bolt长项目中断问题的工程解法
在使用 Cursor、Lovable、Bolt.new 等 AI 编程智能体时,连续对话约 15 到 20 轮后,模型可能开始遗忘边界条件、破坏已有逻辑,甚至虚构数据结构。本文围绕长项目中的上下文衰减问题,整理结构化 PRD、任务拆分、检查点和工作流编排等工程方法。
-
AI 写 Python 代码时最容易埋下的一个安全隐患:SQL 注入
AI 生成的 Python 代码经常使用 f-string 拼接 SQL,这种写法可读性强,却容易带来 SQL 注入风险。开发者需要在代码审查、IDE 插件和自动化检测环节建立防线。
-
T3 Code:把多个 AI 编程 Agent 放进同一个控制台
T3 Code 是一个开源的 AI 编程 Agent 控制台,可将 Claude Code、Codex、OpenCode、Cursor 和 Grok Build 等工具放入统一控制平面,并支持手机、浏览器和桌面远程调度。
-
AI 编程助手留下的代码,谁来负责?一套可写进团队 Wiki 的治理 SOP
AI 编程助手降低了代码生成成本,但没有降低维护成本。团队真正需要的,是一套写进 Wiki 的 SOP:谁审核、谁归档、谁负责、谁承担风险。
-
AI 重构旧组件,不能从“帮我重写”开始
AI 可以快速重写一个旧 React 组件,但真正的风险在于隐藏依赖、失效假设和模糊边界。本文以一场面试案例为线索,整理出画依赖图、识别隐藏假设、按副作用拆分、给 AI 可验证指令的重构方法。