1. 代码大模型对于工程理 解的探索研究 腾讯云 产品专家/ 汪晟杰

2.

3. 01 编码过程的辅助 • 代码大模型的内核 • IDE的新体验 • 下一代编码变革 • 提示词的3S原则

4. AI 及新技术探索诉求日益强烈 根据 survey.stackoverflow.co 统计 正在或计划使用 70% 编写代码 82.55% 代码学习者可能性更高 代码测试 75.81% 代码纠查 77.99% 根据 内部问卷反馈 提升开发效率 48% 工具智能化 24% AI新技术探索 16% 经验复用 12%

5. 代码本质的几大特征 01 秩序性 02 逻辑性 03 上下文感知性

6. 代码大模型本质要解决 01 Token/算力成本 02 语料/意图理解 03 质量/自动化评测

7. 代码大模型的产品赛道可见的价值 01 数据安全 = 好 02 IDE+编码效能 = 快 03 对话+工程理解 = 准

8. 智能编码下衍生的SMAF诉求 【应用形态】打造流畅高效的编程体验 【模型】 探索适合代码场景的行业模型 q LLaMa系的模型 token window size 有限 q 针对专业开发者，提升工作效率和质量，对AI辅 （ 2048），涉及到代码理解/生成这类 助生成的代码存在批判性思维 prompt/output 任务，易因超出token长度限制或 q 针对代码学习钻研用户，专注代码本身，创建小 由于上下文信息不全导致任务中断 的、即时使用的任务型应用程序 q LLaMa系模型 humanEval 和 MBPP 测试结果 q 响应速度更快、成本更低，基于更小的模型？ 低于专用代码生成模型 q LLaMa 是综合模型， 预训练阶段私用代码知识库仅占 6.5%，工程知识量存在天花板 q 具备高粘度的编程体验，及时补全将调用的函数、方法等辅助性编码实践下文 【企业需求】符合国内行业客户诉求——SMAF 代码安全 q 保证基础模型里用于训练的代码 是安全的 q 保障补全出来的代码是安全的 S 多模能力 q 各部门的业务特性不同，可能需 q 如何保障二次训练以及行业代码 q 根据不同业务特性，进行二次训 M aaS 丰富场景 q 代码补全是高频场景，优先度最 高 的训练效果 要多个性化行业模型 练，补全模型 ecurity 数据看板 q 有哪些效能指标，可以帮助管理 q AI 编码辅助之外，代码扫描、评 者观察工具对开发工作的提升 审、以及DevOps上下游规划 A nalysis F ull

9. 全链路 – N+1+1 代码补全 技术对话 4+1+1 成本与体验的拉扯 单元测试 管理 平台 模型工厂 训练 • 用相对较低的推理成本，batch 计算， 小于300ms的延迟 • 预训练更小的代码模型 • SFT 微调 全链路 遥测 代码诊断 代码生成率 推理 成 本 代码采纳率 耗时情况 体 验 •基于混元进行大模型指令对齐和强化学习 •进行行业模型的训练和推理优化，提升产品响应速度与交互体验 •反馈真实场景下的bad base，挖掘行业场景价值 对话采纳率 QPS 测试生成率 数据 运营

10. IDE + AI 打造原生效果的AI辅助的IDE形态

11. VSCode 实验性原生交互接口 探索如何将 AI 更深入地集成到 VS Code 中，并 提出了许多很酷的想法，例如改进的重命名和重 构、基于示例的代码转换以及使用创建文件 glob 模式或正则表达式的方法自然语言。 -- 摘自 vscode 的blog chat：可能是关于聊天功能的 API 提案。 inlineCompletionsAdditions：可能是关于内联补全添加的 API 提案。 interactive：可能是关于交互功能的 API 提案。 documentPaste：可能是关于文档粘贴的 API 提案。 interactiveUserActions：可能是关于交互用户行为的 API 提案。 chatProvider：可能是关于聊天提供者的 API 提案。 codeActionAI：可能是关于代码行为 AI 的 API 提案。 findTextInFiles：可能是关于在文件中查找文本的 API 提案。 textSearchProvider：可能是关于文本搜索提供者的 API 提案。 terminalDataWriteEvent：可能是关于终端数据写入事件的 API 提案。 terminalExecuteCommandEvent：可能是关于终端执行命令事件的 API 提案。 terminalSelection：可能是关于终端选择的 API 提案。 terminalQuickFixProvider：可能是关于终端快速修复提供者的 API 提案。 handleIssueUri：可能是关于处理问题 URI 的 API 提案。 readonlyMessage：可能是关于只读消息的 API 提案。 chatVariables：可能是关于聊天变量的 API 提案。 mappedEditsProvider：可能是关于映射编辑提供者的 API 提案。 aiRelatedInformation：可能是关于 AI 相关信息的 API 提案。 chatAgents：可能是关于聊天代理的 API 提案。 chatAgents2：可能是关于聊天代理2的 API 提案。 chatAgents2Additions：可能是关于聊天代理2添加的 API 提案。 defaultChatAgent：可能是关于默认聊天代理的 API 提案。 这些 API 提案的具体含义和实现细节，通常会在项目的文档或者相关的提案文 档中有详细的描述。如果你想了解更多关于这些 API 提案的信息，你可能需要 查阅这些文档。

12. 以AI为内核的IDE，布局下一代开发者利器 01 AI化的IDE体验 02 利用本机算力 03 云和仓库的增值

13. 下一代编码变革 01 提示词工程与3S原则 02 习惯:问+编码停顿 03 更注重注释文档

14. 提示词工程

15. 智能编码习惯的 3TNB目标 – Tab Tab Tab No Backspace q 根据注释生成代码 q 根据函数定义，生成函数体实现 q 根据上文生成下文代码 q 根据当前代码行输入，补全整行代码 1. 根据注释补全函数体 2. 补全依赖的新函数实现 3. 根据上文补全下文 4. 根据上文补全下文 5. 根据上文生成测试函数 腾讯混元大模型

16. 提示工程在代码场景下的重要性

17. Github Copilot 提示工程的示例 你是一名编码助理，通过澄清用户的问题并提供用户可以搜索的相关关键字列表来帮助用户回答其工作区中有关代码的问题。 用户会向您提供工作区中潜在的相关信息。这些信息可能不完整。请不要提及或要求用户提供更多信息。 您只需澄清并提供关键字。 不要试图直接回答用户的问题。 # 附加规则 逐步思考： 1. 阅读用户的问题，了解他们提出的关于工作空间的问题。 2. 如果问题中有模棱两可的词语，例如 "它"、"那个"、"这个"，请查看对话历史记录来理解这些词语。 3. 输出问题的澄清版本，并解决所有歧义。在澄清问题时，请务必保留问题的意思。 4. 然后输出相关关键词的简短标记符列表，用户可以尝试搜索这些关键词来回答他们的问题。这些关键词可以用作文件名、符号名、缩写或相关代码中的注释。将与问题最相关的关键词放在前面。不要包含过于通 用的关键词。 5. 对于 Markdown 相关关键字列表中的每个关键字，如果适用，请在其后添加一个逗号分隔的变体列表。例如：对于 "encode"，可能的变体包括 "encoding"、"encoded"、"encoder"、"encoders"。考虑同义 词和复数形式。 # 示例 用户：base64 编码的代码在哪里？ 回复： base64 编码的代码在哪里？ - base64 encoding, base64 encoder, base64 encode - base64, base 64 - encode, encoded, encoder, encoders"

18. 提示工程的准度的3S准则 提示工程的基本原理，可以总结为3个S 如下。这些核心规则是创建有效提示的基础。 • 单个 Single：始终将提示集中在单个、定义明确的任务或问题上。 • 具体 Specific：确保说明明确且详细，最好能附带一个示例或者模拟信息结构。具体且具象带来 理解会带来更精确的代码建议。 • 简短 Short：在具体的同时，保持提示简明扼要。这种平衡确保了清晰度，而不会使腾讯云AI代 码助手超载或使交互复杂化。

19. 六大定律 • 定律一：有想法的程序员无法替代。智能编码目前代码速写辅助，依然需要你有开发思路。 • 定律二：学会引导AI，学会提示词，AI是你记忆存储。 • 定律三：每个模型的习性不同，提示词会不同，你要像训练小狗一样摸透他，即使你不懂大模型 原理。 • 定律四：好好做好架构复用，不然你的代码里都是重复代码 • 定律五：用上手了，代码补全留存高于对话。AI理解工程代码，还需要传统方式相结合。 • 定律六：软件工程不会被AI颠覆，流程但会被简化，被智能化。学会定义上层提示词DSL，编排 是未来开发者的技能之一。

20. 智能编码辅助实战

21. 02 工程理解的辅助 • 工程场景的代码语义增强搜索 • 对话：企业知识库RAG • 补全：跨文件能力 • 特性提示词扩展

22. 工程场景下的项目创建开始 @workspace /new

23. 语义增强检索的几大特征 01 Codebase Indexing 02 强化搜索 03 Embedding&速度

24. 企业知识库RAG 扩展上下文感知能力 @workspace #codebase 本质上是在完成提示词的精简化工程的上下文

25. 补全引入更多的工程策略可行性方案 01 02 03 打开过的文件 基于语法特性 目录相关性 相邻选项卡 不同语言 同包下

26. 代码补全 + 跨文件 实战

27. 特性提示词扩展 Prompt as Code

28. 03 AISE的探索与挑战 • 单元测试增强探索 • 智能体 • Devin & Copilot Workspace

29. 软件工程3.0迈入AI时代

30. 研发流程+AI ： 艰巨但一步步，未来可期 产品/项目经理 开发人员 q自动/辅助完成项目计划制定和排期 qAI辅助结对编程 q辅助完成需求细化、拆分以及分解到用户故事和任务 q代码补全和生成 q代码分析和交互式代码生成 q自动生成验收标准 q辅助调试，安全问题监测和性能改进 q代码反向工程生成项目文档 q基于AI给出代码评审意见，辅助完成源代码评审，打破技术鸿沟 AI 辅助的端到端软件研发过程 市场人员 市场人员 设计师（UI/UX） 市场人员 q用户行为分析 q自动生成UI原型 q大量用户反馈数据处理 q基于原型自动生成可用的界面代码 q提取并生成高质量产品需求、改进点 （html/CSS）组件 测试人员 q基于用户故事生成测试用例、测试 步骤和预期结果 q从代码自动生成测试脚本 q根据数据结构描述自动生成大量场 景化测试数据 q自动执行生成的测试自动化脚本 技术支持 q海量日志分析和关键信息提取 q自动分析运维问题并定位到代码 q根据内部知识库快速检索和响应用户问 题，提高用户满意度

31. 为什么说单元测试做的好，很难 为什么说单元测试是软件工程3.0 必须要解决的 01 02 03 测试方法种类多 项目本身不具备可单测 生成质量难以运行 框架多 难以mock 无标准最佳实践

32. 大模型的单元测试可行性 01 增加示例代码 感知框架 02 语法树找相关跨文件 依赖文件的调用链 03 策略感知Mock对象 生成完成可执行单测

33. CoT 与 智能体在开发中的价值 01 02 03 CoT Funtion Call ReAct 思维树拆解 业务逻辑单元 推理+行动

34. @workspace /newNotebook 调研与CoT实战 1.生成需求拆解的几个子 任务，通过title 和 content组装。 2.在组装成子任务的数据 集的时候，我们给出了组 装示例，以稳定大模型的 生成质量。 3.根据子任务，组装成子 任务所需执行的提示词列 表。用于用户点击创建文 件后依次执行代码文件。

35. 开放话题：未来形态是怎样？ 云端IDE加速AI助手为新的载体

36. 04 关注与总结 • 总结 • 腾讯云AI代码助手

37. 小结一下 • 下一个AI时代改变了编码习惯和过程。大模型提供了在开发者赛道下产品化 的无数新场景，但同时也存在技术挑战，中文语料、数据安全性和隐私保护 等问题，也需要考虑在受限资源下多模型怎么落地运转。 • 深度探索提示工程、代码模型能力和AI应用框架是AI产品的重要组成部分， 它们可以帮助我们更好地定义新的软件模式。 • 产品开发指标会作为新的效能度量，和产品改进的手段。 • 3TNB是产品努力方向、3S原则是提示词准则、六大定律是发现机遇的钥匙。 • 对话+RAG、补全+跨文件，有效解决了企业痛点，延伸代码和知识库的理解。

38. 面向企业及个人的腾讯云 AI 代码助手 https://cloud.tencent.com/product/acc

39.

40.