作为一名老登前端开发，这两年深刻感受到大模型时代 AI 对软件工程带来的冲击——也被近年来 AI 各种范式大潮冲击了一遍又一遍。一路从提示词工程，再到上下文工程、Vibe Coding，再到本篇要介绍的 Harness 工程化，一路在思考：什么样的 AI 工程化方案，才是符合 WeTV（腾讯视频海外平台）当下 Web 项目的？这里抛砖引玉，和大家一起来探讨。 【为了将每个细节讲到味，篇幅较长，文章有问题的地方欢迎指出，大佬们不吝点赞+收藏！】
一篇属于后端微服务 + 前端微应用大仓的 Harness 实战分享。 不讲理念有多重要，只讲我们这一路是怎么搭起来、怎么撞墙、撞完怎么补的。
随着大语言模型的普及，流式输出（Streaming）已成为 对话式 AI 应用的标准交互模式：模型逐 Token 生成内容，前端实时增量渲染。此前，我们已面向 Web 端推出了流式友好的 Markdown 渲染器 @ant-design/x-markdown[1]。然而，小程序端缺乏浏览器原生的 HTML 渲染能力，流式 Markdown 渲染会面临格式突变、频繁重解析、性能损耗等问题，我们对现有主流小程序 Markdown 渲染方案进行了研究，发现其在流式场景下存在以下核心局限。
本文是一份 LLM 微调 AutoResearch 落地实战。作者把过去几个月在电商场景（Query 改写 / 同款判定 / 重排打分）上做 Qwen3 微调时的完整流水线沉淀成一个由 Agent 驱动的三阶段框架：场景诊断 → 方案设计 → 自动化实验，同时把踩过的坑（PyTorch 2.6 vs DeepSpeed、Qwen3 thinking mode 让 BLEU 掉到个位数、多队列 OSS endpoint 差异）一并写成 SKILL.md 交给 Agent 执行。文章适合关注 AI Coding、Agent for ML、LLM 微调工程化的同学阅读。文中提到的部分平台/工具（如星云、TuningFactory、TAO/Pailitao-AutoResearch）为公司内部命名，思路和方法本身与平台无关，读者可类比到 PAI、SageMaker、Slurm 等外部环境。（文章内容基于作者个人技术实践与独立思考，旨在分享经验，仅代表个人观点。）
AI 写代码越来越快，网盘主端 FE 团队每月约 2000 次 CR 中，AI 生成代码占比已达 55.87%。代码产出速度提升，传统人工 Code Review 的压力同步放大——Reviewer 不仅要看代码风格，还要判断逻辑、调用链、API 契约和高危问题，精度与专注度双双下降。本文分享了他们如何在 CI/CD 流水线中嵌入 AICR 强制检测链路，用多维度多角色 AI 审查为人工 Reviewer 减负，以及建设过程中对检测耗时、误报治理、模型选型等问题的实战思考。
过去一段时间，AI Agent 相关工具出现了一个有意思的变化：能力在不断演进，交互入口却越来越多地回到最朴素的命令行。看起来像是一次「复古回归」，背后其实藏着一个更本质的判断：当软件的操作者从人扩展到 Agent，CLI 不再只是给工程师用的老工具，它可能成为 Agent 调用数字世界的高效入口。 不禁想到，今年笔者所在的部门对平台智能化升级提了「AI 友好」这一目标。那么，怎样的平台才算 AI 友好？难道 CLI 就等于 AI 友好？带着这些问题，这段时间做了一些思考，记录下来做下分享。
AI Native 不仅指产品形态。在一些更窄的场景里，比如编程领域，它也可以特指 AI Native 研发。但这里的AI Native 研发，不是让 Agent 写更多代码，也不是让 AI 零散参与研发流程，而是在清晰边界、可观测 checkpoint 和可验证闭环下，让代码生成、测试、修复、验证等实施动作尽可能由 AI 连续完成。人的角色不消失，而是上移到设定目标与边界、审阅 checkpoint、判断转向和最终验收。（文章内容基于作者个人技术实践与独立思考，旨在分享经验，仅代表个人观点。）
