Repository: phodal/aise Branch: master Commit: c84d52022c3b Files: 96 Total size: 449.4 KB Directory structure: gitextract_krez1up2/ ├── .github/ │ └── workflows/ │ └── mdbook.yml ├── .gitignore ├── .shire/ │ ├── commit-message.shire │ ├── extend-content.shire │ ├── optimize.shire │ └── research/ │ ├── placeholder.md │ ├── research.shire │ └── summary.shire ├── .shire-output/ │ └── gen-ai-ops.md ├── README.md ├── book.toml ├── code/ │ ├── ch0/ │ │ └── hello-world.shire │ └── ch1/ │ ├── basic-refactor.shire │ └── refactoring-with-context.shire ├── src/ │ ├── README.md │ ├── SUMMARY.md │ ├── agent-codebase-example.md │ ├── agent-coding-task.md │ ├── agent-copilot-workspace.md │ ├── agent-data-security.md │ ├── agent-debug.md │ ├── agent-for-aise.md │ ├── agent-github-copilot-chat.md │ ├── agent-in-local-design.md │ ├── agent-infrastructure.md │ ├── agent-onboarding.md │ ├── agent-refactoring-test.md │ ├── agent-remote.md │ ├── agent-understand-rag.md │ ├── ai4se-2024-summary.md │ ├── ai4se-agentic-chat.md │ ├── ai4se-design-principle.md │ ├── ai4se-github-ai-platform.md │ ├── ai4se-gitlab.md │ ├── ai4se-google-dev-activity-driven.md │ ├── ai4se-lifecycle.md │ ├── ai4se-sql.md │ ├── ai4se-tabnine-devops-driven.md │ ├── ai4se.md │ ├── aise-api-test.md │ ├── aise-code-check.md │ ├── aise-code-completion.md │ ├── aise-code-review.md │ ├── aise-commit-message.md │ ├── aise-dev.md │ ├── aise-digital-engineering.md │ ├── aise-e2e-test.md │ ├── aise-fix-issue.md │ ├── aise-for-arch.md │ ├── aise-gen-cli.md │ ├── aise-gen-comment.md │ ├── aise-gen-doc.md │ ├── aise-gen-snippet.md │ ├── aise-knowledge-management.md │ ├── aise-low-code-gen.md │ ├── aise-platform-engineering.md │ ├── aise-quality.md │ ├── aise-requirement.md │ ├── aise-test-case.md │ ├── aise-test-code.md │ ├── aise-testing.md │ ├── aise-ui-code-gen.md │ ├── aise-ui-design.md │ ├── aise-ui-interaction-gen.md │ ├── design-aise.md │ ├── design-example-refactor.md │ ├── flow-aise.md │ ├── flow-example-autocrud.md │ ├── flow-in-aise.md │ ├── future.md │ ├── gen-ai-for-ops.md │ ├── gen-ai-pipeline.md │ ├── gen-arch.md │ ├── gen-ci-cd.md │ ├── gen-cicd.md │ ├── gen-monitor.md │ ├── gen-root-cause.md │ ├── gen-sql.md │ ├── images/ │ │ ├── Lossless-Semantic-Trees.avif │ │ ├── java-lst-demo.avif │ │ └── text-to-sql.avif │ ├── jetbrains-agentic-chat.md │ ├── metric-evaluation.md │ ├── metric-matrix.md │ ├── metric-setup.md │ ├── metric.md │ ├── microsoft-modern-software-engineering.md │ ├── practise-ai4se-env-setup.md │ ├── practise-ai4se-landscape.md │ ├── reference.md │ ├── scenario-aise.md │ ├── scenario-legacy-refactor.md │ ├── scenario-legacy-transform.md │ ├── scenario-team-ai.md │ └── windsurf-agentic-chat.md └── theme/ └── custom.css ================================================ FILE CONTENTS ================================================ ================================================ FILE: .github/workflows/mdbook.yml ================================================ # Sample workflow for building and deploying a mdBook site to GitHub Pages # # To get started with mdBook see: https://rust-lang.github.io/mdBook/index.html # name: Deploy mdBook site to Pages on: # Runs on pushes targeting the default branch push: branches: ["master"] # Allows you to run this workflow manually from the Actions tab workflow_dispatch: # Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages permissions: contents: read pages: write id-token: write # Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued. # However, do NOT cancel in-progress runs as we want to allow these production deployments to complete. concurrency: group: "pages" cancel-in-progress: false jobs: # Build job build: runs-on: ubuntu-latest env: MDBOOK_VERSION: 0.4.36 steps: - uses: actions/checkout@v4 - name: Install mdBook run: | curl --proto '=https' --tlsv1.2 https://sh.rustup.rs -sSf -y | sh rustup update cargo install --version ${MDBOOK_VERSION} mdbook - name: Setup Pages id: pages uses: actions/configure-pages@v5 - name: Build with mdBook run: mdbook build - name: Generate sitemap run: | cd book npm i -g static-sitemap-cli npx sscli --no-clean --base https://aise.phodal.com - name: Upload artifact uses: actions/upload-pages-artifact@v3 with: path: ./book # Deployment job deploy: environment: name: github-pages url: ${{ steps.deployment.outputs.page_url }} runs-on: ubuntu-latest needs: build steps: - name: Deploy to GitHub Pages id: deployment uses: actions/deploy-pages@v4 ================================================ FILE: .gitignore ================================================ book .idea ================================================ FILE: .shire/commit-message.shire ================================================ --- name: "Commit message" interaction: AppendCursor actionLocation: CommitMenu onStreamingEnd: { parseCode | updateEditorText } --- 请为给定的变更（Diff）编写一个连贯但具有描述性的代码提交信息。 背景信息：我现在使用 Git 编写一本开源电子书《AI 辅助软件工程：AI IDE 插件与编程智能体示例》，我需要为每个提交编写一个简洁但具有描述性的提交信息。 要求： - 确保包含修改了什么以及为什么。 - 以不超过 50 个字符的祈使句形式开头。 - 然后留下一个空行，如有必要，继续详细说明。 - 如果变更是一个 .shire 文件，说明我添加了一个新的示例。 遵循常规提交规范，例如： - fix(authentication): 修复密码正则表达式模式问题 - feat(storage): 添加对S3存储的支持 - test(java): 修复用户控制器的测试用例 - docs(architecture): 在主页添加架构图 Diff： $currentChanges ================================================ FILE: .shire/extend-content.shire ================================================ --- name: "扩写内容" description: "根据如下的内容，扩写现有的文本。" interaction: RunPanel actionLocation: ContextMenu --- 请你根据以下内容，对现有的文本进行扩写，使其更加详尽和生动。请在回答中包含扩写后的完整文本。 文章的大纲如下: $structure 待修改的内容如下： ```$language $selection ``` 你只需要对上述内容进行扩写，使其更加详尽和生动。 ================================================ FILE: .shire/optimize.shire ================================================ --- name: "优化表达" interaction: ReplaceSelection --- 请对如下的内容进行优化，使其更符合书写规范和表达要求。要求： 1. 中英文之间请添加空格。 2. 请让内容应该更符合中文表达习惯。 3. 尽量避免使用过长的句子。 4. 如果有将第一人称叙事方式改为第三人称叙事方式。 请在回答中包含优化后的完整文本。 $selection ================================================ FILE: .shire/research/placeholder.md ================================================ # PromptLayer 案例 - [How Ellipsis uses PromptLayer to Debug LLM Agents](https://blog.promptlayer.com/how-ellipsis-uses-promptlayer-to-debug-llm-agents/) - [How Speak Empowers Non-Technical Teams with Prompt Engineering and PromptLayer](https://blog.promptlayer.com/how-speak-empowers-non-technical-teams-with-prompt-engineering-and-promptlayer/) - [How PromptLayer Enables Non-Technical Prompt Engineering at ParentLab](https://blog.promptlayer.com/how-promptlayer-enables-non-technical-prompt-engineering-at-parentlab/) - [Gorgias Uses PromptLayer to Automate Customer Support at Scale](https://blog.promptlayer.com/gorgias-uses-promptlayer-to-automate-customer-support-at-scale/) ================================================ FILE: .shire/research/research.shire ================================================ --- variables: "crawl": /gen-ai-for-ops\.md/ { capture("src/gen-ai-for-ops.md", "link") | crawl() | thread(".shire/research/summary.shire") } "article": /gen-ai-for-ops\.md/ { cat } onStreamingEnd: { saveFile("src/gen-ai-for-ops.md") } --- 根据如下的草稿和对应的资料，编写一篇对应主题的文章。 文章草稿如下： $article 相关的资料如下： $crawl ================================================ FILE: .shire/research/summary.shire ================================================ 总结文章，罗列出文章的技术关键信息，方便我写作时作为参考： $output ================================================ FILE: .shire-output/gen-ai-ops.md ================================================ 根据如下的草稿和对应的资料，编写一篇对应主题的文章。 文章草稿如下： # AI 辅助软件工程：AI 运维 ## 行业趋势 - NewRelic - 构建生成式 AI 应用的可观测性 - 无缝辅助从异常到错误代码修复建议 - 文档问答、自然查询语言转换等。 - PageDuty - 日常聊天助手辅助（PageDuty Copilot） - 总结问题、起草事故回顾报告等文本工作 - 辅助生成 Runbook 自动化任务代码 - Dynatrace - 自动化的根因分析 - 自然语言转化 Dynatrace 查询语言（DQL） - Davis CoPilot 辅助生成工作流代码 - Datalog - 辅助诊断问题，确定范围及修复问题 - 自然语言查询数据 - 撰写事故分析的初稿和防范（自动化测试） ## AI 运维 Copilot 问题示例： - 告警来自哪里？ - 相关的服务及其状态是什么？ - 在过去的24小时内发生了什么变化？ - 这个事故之前是否发生过？ - 这些变化中是否有任何可能是事故原因的？ - 将@用户名添加为响应者 - 运行工作流{工作流名称} - 确认该事故 - 帮我了解最新情况 - 解决该事故 ## 运营驱动 > 产品类的问答对准确性要求高，对幻觉容忍度相对低，需要搭建运营机制多重保障落地 - 冷启动运营： - LLM辅助从文档抽取FAQ - 队伍进一步审核入库FAQ - 日常检视运营： - 是否需要补充更多材料数据？ - 是否高频问题落到FAQ通道？ - 哪些需要进一步结构化？ - 模型持续运营： - 意图识别数据标注&模型迭代 - 向量相似召回数据标注&模型迭代 ## 相关资料 - [Introducing Bits AI, your new DevOps copilot](https://www.datadoghq.com/blog/datadog-bits-generative-ai/) - [Dynatrace expands Davis AI with Davis CoPilot, pioneering the first hypermodal AI platform for unified observability and security](https://www.dynatrace.com/news/blog/hypermodal-ai-dynatrace-expands-davis-ai-with-davis-copilot/) - [PagerDuty Announces the Latest Capability from PagerDuty Copilot, a Set of Generative AI-Enabled Use Cases Available Across the PagerDuty Operations Cloud ](https://www.pagerduty.com/newsroom/pagerduty-copilot/) - [Meet the first GenAI assistant for observability](https://newrelic.com/blog/nerdlog/new-relic-ai-assistant) 相关的资料如下： 以下是对文章的技术关键信息的总结： **技术关键信息：** 1. **产品介绍：** - Bits AI 是由 Datadog 开发的一款基于生成式人工智能的 DevOps 辅助工具。 - 它通过 Datadog 平台提供单一的对话式界面，帮助用户从多个数据源中获取和关联关键信息。 2. **功能特点：** - **环境监控：** Bits AI 可以快速诊断问题并确定影响范围。 - **数据查询：** 支持自然语言查询，帮助用户快速发现相关指标、跟踪和日志。 - **事件响应：** 流程化的事件响应和修复，包括自动声明事件、通知团队成员、更新事件严重性等。 - **问题预防：** 帮助编写事后总结，创建合成测试以预防问题再次发生。 3. **使用场景：** - **快速诊断：** 在生产环境中检测到问题时，使用 Bits AI 进行快速诊断。 - **深入调查：** 通过自然语言查询深入调查问题的根本原因。 - **流程优化：** 在事件响应过程中，自动提供事件总结和关键资产，如运行手册和修复指南。 - **测试创建：** 根据用户提示或分析创建合成测试，以验证服务的可用性和性能。 4. **集成与协作：** - Bits AI 可以与 Datadog 的其他产品（如日志管理、APM）以及 Slack 和 PagerDuty 等工具集成。 - 在 Slack 频道中自动为新加入的响应者提供事件总结。 5. **技术优势：** - Bits AI 通过理解组织如何标记服务和基础设施，将用户的提示转换为正确的查询语法，使任何人都能轻松获取关键信息。 - 通过生成式 AI，自动执行许多行政任务，减少人工负担。 6. **可用性：** - Bits AI 目前以私有测试版的形式提供，可通过填写表格请求访问。 - 新用户可以免费试用 Datadog 平台 14 天。 这些信息可以作为写作时参考的技术要点，帮助读者理解 Bits AI 的核心功能和优势。 以下是对文章的技术关键信息的总结： 1. **Davis CoPilot™的推出**：Dynatrace宣布推出Davis CoPilot™，这是在其Davis® AI平台中加入生成式AI能力后的成果，使其成为业界首个超模态AI平台。 2. **超模态AI (Hypermodal AI)**：结合了预测AI、因果AI和生成AI，以提高运营、安全、开发和业务团队的生产力。 3. **Davis AI的功能**： - **预测AI**：使用机器学习和统计方法，基于过去的数据推荐未来的行动。 - **因果AI**：处理可观察性、安全和业务数据，以确定问题的根本原因、安全风险、用户影响，并触发自动修复措施。 - **生成AI**：通过AI驱动的分析和自动化，为组织内的所有成员提供生产力提升。 4. **Davis CoPilot的特点**： - 使用自然语言创建查询、数据仪表板和数据笔记本。 - 提供自动化工作流的代码建议。 - 简化和加速Dynatrace平台的入门、配置和采用。 5. **AI技术的结合**：预测AI和因果AI为生成AI提供确定性的答案和可靠的自动化，而精确的上下文则丰富了生成AI的自动或用户创建的提示。 6. **应用场景**：Davis AI通过其不同的AI技术，支持可观察性、安全和业务用例，例如自动根本原因分析、自然语言查询、自动编码工作流、预测性操作、自动生成的质量检查、AI驱动的应用程序安全性和自然语言到视觉分析的转换。 7. **可用性**：Davis AI的预测AI和因果AI功能目前已可供所有Dynatrace客户使用，而Davis CoPilot™计划于2023年晚些时候作为Dynatrace平台的核心技术推出。 这些信息可以作为您撰写相关文章时的参考。 文章标题：Featured PagerDuty Advance Generative AI for critical operations work. Explore now 技术关键信息： 1. **产品名称**：PagerDuty Advance Generative AI 2. **应用领域**：关键业务运营工作（Critical Operations Work） 3. **技术特点**： - **生成式AI**：利用先进的生成式人工智能技术，能够自动生成内容或提供决策支持。 - **实时响应**：针对关键业务场景，提供实时响应和决策支持，以优化运营效率。 - **自动化**：通过自动化功能，减轻人工负担，提高工作效率。 4. **目标用户**：需要进行关键业务运营的企业和组织。 5. **探索机会**：文章鼓励用户探索和了解这一技术，以便在写作时作为参考。 在写作时，可以关注以下方面： - 生成式AI在关键业务运营中的应用案例和效果。 - PagerDuty Advance Generative AI如何帮助用户提高工作效率和准确性。 - 该技术的市场前景和潜在影响。 - 用户如何开始使用和探索这一技术。 以下是对文章《How to Relic Best Practices Culture News》的技术关键信息总结： 1. **文章主题**：介绍New Relic推出的首个面向观测性的生成式AI助手，旨在使观测性对所有用户更加易于访问和使用。 2. **核心功能**： - 使用大型语言模型（LLMs）和New Relic统一遥测数据平台，用户可以通过简单的提问获得系统状态的深入洞察。 - 提供一个熟悉的聊天界面，用户可以询问New Relic AI问题，并获得系统异常的深度分析、见解和建议修复方法。 - 使非技术用户和开发、运维、安全、产品、支持、测试团队等能够更快地解决问题，减少停机时间，提高开发速度和创新。 3. **技术优势**： - 将大量数据合成为清晰的见解，帮助用户从众多仪表板、文档、运行手册、警报、异常、日志和跟踪中区分信号和噪声。 - 通过统一的数据库，New Relic AI可以从多个角度分析问题，生成见解。 4. **应用场景**： - 加速新遥测数据源的配置和监控。 - 自动识别代码级错误并建议修复方法。 5. **产品集成**： - New Relic AI与OpenAI GPT系列API的集成，用于监控应用程序。 6. **未来发展**： - New Relic正在扩展其生成式AI功能，包括使用机器学习模型进行预测分析，优化AI实施，并使观测性更加易于访问。 7. **用户指南**： - 提供文档指导用户如何开始使用New Relic AI。 - 提供免费账户，包括100 GB/月的免费数据摄入和访问30+功能。 8. **作者信息**： - 作者Camden Swita是New Relic产品管理总监，负责New Relic AI、变更跟踪和查看功能。 9. **法律声明**： - 文章包含前瞻性声明，可能涉及风险和不确定性，实际结果可能与声明不同。 10. **相关资源**： - 提供了与文章相关的其他观测性文章和集成资源链接。 -------------------- # AI 辅助软件工程：AI 运维的未来趋势 随着技术的不断进步，人工智能（AI）在软件工程领域的应用日益广泛，尤其是在运维（Operations）方面。AI 辅助运维正在成为行业趋势，多家知名企业如 NewRelic、PageDuty 和 Dynatrace 等都在积极开发和应用相关技术。本文将探讨 AI 运维的最新趋势及其对软件工程的影响。 ## 行业趋势 ### NewRelic：构建生成式 AI 应用的可观测性 NewRelic 推出了基于生成式人工智能的辅助工具，它能够通过自然语言处理（NLP）技术，帮助用户从多个数据源中获取和关联关键信息。 该工具不仅能够提供异常到错误代码修复的建议，还能进行文档问答和自然查询语言转换等。 ### PageDuty：日常聊天助手辅助 PageDuty 的 Copilot 功能利用生成式 AI，为运维人员提供日常聊天助手。它能够总结问题、起草事故回顾报告等文本工作，并辅助生成 Runbook 自动化任务代码，从而提高运维效率。 ### Dynatrace：自动化的根因分析 Dynatrace 的 Davis AI 平台通过引入 Davis CoPilot，进一步增强了其自动化根因分析的能力。它支持自然语言转化 Dynatrace 查询语言（DQL），并辅助生成工作流代码，简化了运维流程。 ### Datalog：辅助诊断问题 Datalog 的 AI 运维工具能够辅助诊断问题，确定范围及修复问题。它支持自然语言查询数据，并撰写事故分析的初稿和防范措施，如自动化测试。 ## AI 运维 Copilot AI 运维 Copilot 是一种智能辅助工具，它能够回答一系列运维相关问题，如告警来源、相关服务状态、过去24小时内的变化等。Copilot 还能执行一系列操作，如添加响应者、运行工作流、确认事故等，从而实现自动化运维。 ### 问题示例 - **告警来自哪里？** - **相关的服务及其状态是什么？** - **在过去的24小时内发生了什么变化？** - **这个事故之前是否发生过？** - **这些变化中是否有任何可能是事故原因的？** - **将@用户名添加为响应者** - **运行工作流{工作流名称}** - **确认该事故** - **帮我了解最新情况** - **解决该事故** ## 运营驱动 为了确保产品类的问答准确性高，对幻觉容忍度相对低，需要搭建运营机制多重保障落地。 ### 冷启动运营 - **LLM辅助从文档抽取FAQ** - **队伍进一步审核入库FAQ** ### 日常检视运营 - **是否需要补充更多材料数据？** - **是否高频问题落到FAQ通道？** - **哪些需要进一步结构化？** ### 模型持续运营 - **意图识别数据标注&模型迭代** - **向量相似召回数据标注&模型迭代** ## 结论 AI 辅助运维正在成为软件工程领域的一个重要趋势。通过生成式 AI、自然语言处理等技术，运维人员能够更高效地处理日常任务，自动化诊断和解决问题。随着技术的不断进步，我们可以期待 AI 运维将在未来发挥更加重要的作用，为软件工程带来革命性的变化。 Process finished with exit code 0 ================================================ FILE: README.md ================================================ # 《AI 辅助软件工程：实践与案例解析》 ![Cover](src/images/cover.jpeg) 2024 年 6 月 1 日，我计划利用在 Thoughtworks 的三个月年资假做一些 AI 辅助研究与超前设计。同时结合之前的 AI 辅助软件工程实践经验以及在 Thoughtworks 的开源项目与落地经验，编写一本关于《AI辅助软件工程》的开源电子书。 - 作为一个新晋奶爸，我需要在带娃的业余时间里完成这本书，所以有些调研会比较仓促和写作进度可能会比较慢。但是，我会尽量保证每周至少更新一篇文章。 - 作为一个工程师，我更喜欢能真正落地的方案，而不是纸上谈兵。所以，我花了大量的时间在收集和分析落地案例，以及在实际项目中的实践经验，以避免浪费读者的时间。 这本开源电子书（ https://aise.phodal.com/ ）包含了什么： - 国内外最新的 AI 辅助软件工程实践。我们阅读了大量的国内外生成式 AI 技术博客，收集了从 GitHub、GitLab、Google、JetBrains、Atlassian、New Relic/Dynatrace 等公司的 AI 辅助软件工程实践。 - 从 AI 模型到 IDE 插件的实现细节。作为 IDE 插件 AutoDev 开源项目以及 Shire 编码智能体语言的作者，我会结合实际项目经验，分享如何从 AI 模型到 IDE 插件的实现细节。 - 从编码 RAG 到编码智能体的实践案例与经验。我们收集了大量的编码智能体的实践案例与经验，以及在编码领域如何使用 RAG 模型的实践案例。 这本书没有什么？ - 相关 Paper。作为一个工程师，我更喜欢能真正落地的方案，而不是纸上谈兵。尽管已经有大量的 AI 辅助软件工程的 Paper，从业内的实践经验来看，Paper 与实际落地的差距还是很大的。 如果你对此感兴趣，欢迎加入这个开源项目。 阅读需知： 在大多数组织中，开发者用于编码的时间不到总工作时间的 40%，因此编码提效对整个软件开发生命周期（SDLC）的效能影响很有限，应尝试将 AI 应用于软件 全生命周期和整个团队，而不仅仅是个别成员、个别环节的产出。 更多关于我的信息，请访问我的个人网站：[Phodal](https://www.phodal.com)。或者扫描下方二维码： ![](https://articles.phodal.com/qrcode.jpg) ## 简介 本书是一本关于如何使用 AI 辅助软件工程的开源电子书。我们将介绍： - 如何使用生成式 AI 来在软件工程的不同阶段进行辅助。 - AI IDE 编程工具的 Prompt 技巧。 - 设计 AI 辅助流程来提高软件工程师的工作效率。 - 定制 AI IDE 来融入不同编程任务。 - 设计和构建 AI 编码智能体。 - 如何使用 Shire 与 RAG 来进行 AI 辅助研发。 开始阅读之前，你需要自行了解一些基本概念： - 什么是生成式 AI？ - AI 智能体是什么？ - 什么是 IDE 插件？（我想你是不需要的） 本书不适合以下人群： - 想要了解 AI 基础知识的人。 - 快速入门使用 AI 辅助软件工程的人。 - 想要了解 AI IDE 插件开发的人。 如果你是以上人群，建议你先了解一些基础知识，然后再来阅读本书。 ================================================ FILE: book.toml ================================================ [book] authors = ["Phodal Huang"] language = "en" multilingual = false src = "src" title = "AI 辅助软件工程：实践与案例解析" [output.html] git-repository-url = "https://github.com/phodal/aise" git-repository-icon = "fa-github" edit-url-template = "https://github.com/phodal/aise/edit/master/{path}" site-url = "/" cname = "aise.phodal.com" additional-css = ["theme/custom.css"] ================================================ FILE: code/ch0/hello-world.shire ================================================ Hello, World! ================================================ FILE: code/ch1/basic-refactor.shire ================================================ 请你这段代码建议适当的重构。提高代码的可读性、质量，使代码更加有组织和易懂。 ```java public class Main { public static void main(String[] args) { int a = 5; int b = 10; int c = a + b; System.out.println("Sum: " + c); int d = a - b; System.out.println("Difference: " + d); int e = a * b; System.out.println("Product: " + e); int f = b / a; System.out.println("Quotient: " + f); } } ``` ================================================ FILE: code/ch1/refactoring-with-context.shire ================================================ --- name: "重构代码" actionLocation: ContextMenu --- 请你这段代码建议适当的重构。提高代码的可读性、质量，使代码更加有组织和易懂。你的回答应包含重构描述和一个代码片段，展示重构后的结果。 使用一些众所周知的重构技巧，比如以下列表中的一个： - 重命名 - 修改签名、声明 - 提取或引入变量、函数、常量、参数、类型参数 - 提取类、接口、超类 - 内联类、函数、变量等 - 移动字段、函数、语句等 - 上移构造函数、字段、方法 - 下移字段、方法 请勿生成多个代码片段，尝试将所有更改都整合到一个代码片段中。 请勿生成包含虚构周围类、方法的代码。不要模拟缺失的依赖项。 提供的代码已经整合到正确且可编译的代码中，不要在其周围添加额外的类。 重构以下代码： $selection ================================================ FILE: src/README.md ================================================ # 《AI 辅助软件工程：实践与案例解析》前言 2024 年 6 月 1 日，我计划利用在 Thoughtworks 的三个月年资假做一些 AI 辅助研究与超前设计。同时结合之前的 AI 辅助软件工程实践经验以及在 Thoughtworks 的开源项目与落地经验，编写一本关于《AI辅助软件工程》的开源电子书。 - 作为一个新晋奶爸，我需要在带娃的业余时间里完成这本书，所以有些调研会比较仓促和写作进度可能会比较慢。但是，我会尽量保证每周至少更新一篇文章。 - 作为一个工程师，我更喜欢能真正落地的方案，而不是纸上谈兵。所以，我花了大量的时间在收集和分析落地案例，以及在实际项目中的实践经验，以避免浪费读者的时间。 这本开源电子书（ https://aise.phodal.com/ ）包含了什么： - 国内外最新的 AI 辅助软件工程实践。我们阅读了大量的国内外生成式 AI 技术博客，收集了从 GitHub、GitLab、Google、JetBrains、Atlassian、New Relic/Dynatrace 等公司的 AI 辅助软件工程实践。 - 从 AI 模型到 IDE 插件的实现细节。作为 IDE 插件 AutoDev 开源项目以及 Shire 编码智能体语言的作者，我会结合实际项目经验，分享如何从 AI 模型到 IDE 插件的实现细节。 - 从编码 RAG 到编码智能体的实践案例与经验。我们收集了大量的编码智能体的实践案例与经验，以及在编码领域如何使用 RAG 模型的实践案例。 这本书没有什么？ - 相关 Paper。作为一个工程师，我更喜欢能真正落地的方案，而不是纸上谈兵。尽管已经有大量的 AI 辅助软件工程的 Paper，从业内的实践经验来看，Paper 与实际落地的差距还是很大的。 如果你对此感兴趣，欢迎加入这个开源项目。 阅读需知： 在大多数组织中，开发者用于编码的时间不到总工作时间的 40%，因此编码提效对整个软件开发生命周期（SDLC）的效能影响很有限，应尝试将 AI 应用于软件 全生命周期和整个团队，而不仅仅是个别成员、个别环节的产出。 更多关于我的信息，请访问我的个人网站：[Phodal](https://www.phodal.com)。或者扫描下方二维码： ![](https://articles.phodal.com/qrcode.jpg) ## 简介 本书是一本关于如何使用 AI 辅助软件工程的开源电子书。我们将介绍： - 如何使用生成式 AI 来在软件工程的不同阶段进行辅助。 - AI IDE 编程工具的 Prompt 技巧。 - 设计 AI 辅助流程来提高软件工程师的工作效率。 - 定制 AI IDE 来融入不同编程任务。 - 设计和构建 AI 编码智能体。 - 如何使用 Shire 与 RAG 来进行 AI 辅助研发。 开始阅读之前，你需要自行了解一些基本概念： - 什么是生成式 AI？ - AI 智能体是什么？ - 什么是 IDE 插件？（我想你是不需要的） 本书不适合以下人群： - 想要了解 AI 基础知识的人。 - 快速入门使用 AI 辅助软件工程的人。 - 想要了解 AI IDE 插件开发的人。 如果你是以上人群，建议你先了解一些基础知识，然后再来阅读本书。 ================================================ FILE: src/SUMMARY.md ================================================ # Summary - [简介](./README.md) - [前言：AI4SE 的 2024 趋势](./ai4se.md) - [前言：AI4SE 的 2024 总结](./ai4se-2024-summary.md) - [第 1 部分：AI4SE 体系设计](./design-aise.md) - [AI4SE 体系设计原则](./ai4se-design-principle.md) - [软件生命周期驱动的 AI4SE](./ai4se-lifecycle.md) - [Tabnine：AI 工具与 DevOps 驱动的 AI4SE](./ai4se-tabnine-devops-driven.md) - [Google：开发者活动驱动](./ai4se-google-dev-activity-driven.md) - [GitHub：AI 平台工程赋能开发者](./ai4se-github-ai-platform.md) - [Gitlab：赋能开发者的 AI4SE](./ai4se-gitlab.md) - [第 2 部分：AI IDE 辅助软件工程](./practise-ai4se-landscape.md) - [Agentic Chat](./ai4se-agentic-chat.md) - [WindSurf Agentic Chat](./windsurf-agentic-chat.md) - [JetBrains Agentic Chat](./jetbrains-agentic-chat.md) - [练习环境准备](./practise-ai4se-env-setup.md) - [基于示例展示：重构代码](./design-example-refactor.md) - [研发数字化](./aise-digital-engineering.md) - [知识管理](./aise-knowledge-management.md) - [关联的提交信息](./aise-commit-message.md) - [需求智能化](./aise-requirement.md) - [平台工程](./aise-platform-engineering.md) - [AI 低代码生成](./aise-ui-design.md) - [UI 代码生成](./aise-ui-code-gen.md) - [UI 交互生成](./aise-ui-interaction-gen.md) - [低代码生成](./aise-low-code-gen.md) - [AI 辅助开发](./aise-dev.md) - [代码补全](./aise-code-completion.md) - [代码注释生成](./aise-gen-comment.md) - [代码片段生成](./aise-gen-snippet.md) - [代码文档生成](./aise-gen-doc.md) - [CLI 命令生成](./aise-gen-cli.md) - [AI 辅助软件质量](./aise-quality.md) - [代码质量检查](./aise-code-check.md) - [代码检视](./aise-code-review.md) - [问题修复](./aise-fix-issue.md) - [AI 辅助测试](./aise-testing.md) - [测试用例生成](./aise-test-case.md) - [单元测试生成](./aise-test-code.md) - [API 测试生成](./aise-api-test.md) - [E2E 测试生成](./aise-e2e-test.md) - [AI 辅助 CI/CD](./gen-ci-cd.md) - [流水线生成](./gen-ai-pipeline.md) - [CI/CD 流水线](./gen-cicd.md) - [AI 辅助架构设计](./aise-for-arch.md) - [架构设计生成](./gen-arch.md) - [AI 运维](./gen-ai-for-ops.md) - [SQL 优化生成](./ai4se-sql.md) - [辅助运维监控](./gen-monitor.md) - [辅助根因分析](./gen-root-cause.md) - [第 3 部分：面向场景定制 AI 插件能力](./scenario-aise.md) - [遗留系统重构示例](./scenario-legacy-refactor.md) - [系统迁移](./scenario-legacy-transform.md) - [团队 AI](./scenario-team-ai.md) - [第 4 部分：编程智能体辅助软件工程](./agent-for-aise.md) - [编码智能体基础设施](./agent-infrastructure.md) - [远程 AI 智能体](./agent-remote.md) - [重构 AI 测试生成](./agent-refactoring-test.md) - [场景：新人上手项目](./agent-onboarding.md) - [本地 AI 智能体](./agent-in-local-design.md) - [理解 RAG 应用](./agent-understand-rag.md) - [编码任务 Agent](./agent-coding-task.md) - [Copilot Chat 是如何工作的](./agent-github-copilot-chat.md) - [代码问答 Agent 示例](./agent-codebase-example.md) - [Copilot Workspace](./agent-copilot-workspace.md) - [RAG 数据与 AI 安全](./agent-data-security.md) - [Agent 调试](./agent-debug.md) - [第 5 部分：AI 自动化编程](./flow-aise.md) - [理解 AI 自动化编程](./flow-in-aise.md) - [自动化 CRUD](./flow-example-autocrud.md) - [第 6 部分：评估与度量](./metric.md) - [AI4SE 度量设置](./metric-setup.md) - [AI4SE 度量评估](./metric-evaluation.md) - [AI4SE 度量](./metric-matrix.md) - [未来展望](./future.md) - [参考资料](./reference.md) ================================================ FILE: src/agent-codebase-example.md ================================================ # 编码智能体：代码问答 Agent 示例 ## 问答策略 ### 全局 vs. 局部上下文 ### 远程 vs. 本地相关上下文 ### 业务导向还是技术逻辑导向 ## 示例 ### Sweep：issue-to-pull-request 功能 相关文章：[Sweep's Core Algorithm - Using Retrieval Augmented Generation (RAG) to clear your GitHub Backlog](https://docs.sweep.dev/blogs/sweeps-core-algo) ![Sweep](images/sweep-dev-core-algorithm.svg) Sweep 的核心算法可以总结为以下四个主要阶段： 1. **搜索**： - **目的**：检索相关的代码片段和上下文。 - **过程** ：根据问题描述查询代码库，获取顶级代码片段。使用 [MPNet](https://huggingface.co/sentence-transformers/all-mpnet-base-v2) 向量化和 DeepLake 向量存储。 - **步骤**： - 根据问题上下文搜索代码片段。 - 重排。基于提交计数和最新提交时间的启发式方法对片段进行重新排序 - 去重和合并代码片段。 - 使用 [ctag 总结生成仓库摘要](https://docs.sweep.dev/blogs/understanding-codebase-with-ctags)。 2. **规划**： - **目的**：确定修改和新创建的文件。 - **过程**：分析问题的根本原因并规划变更。 - **步骤**： - 使用自然语言规划实现方案。 - 指定要修改或创建的文件。 - 根据需要验证和调整修改方案。 3. **执行**： - **目的**：在代码库中实施规划的变更。 - **过程**： - 创建新文件或修改现有文件。 - 辨识并描述具体变更及其涉及的行号。 - 使用搜索和替换对进行修改。 - 对于大文件使用流式方法处理。 4. **验证**： - **目的**：确保实施变更的正确性。 - **过程**： - 使用基于LLM和程序的验证检查代码错误和功能。 - 进行自我审查，必要时进行迭代。 - 利用GitHub Actions进行额外的验证。 从搜索代码片段到验证变更的每个阶段都确保了一种系统化的方法，通过自动化流程和GPT-4驱动的类人推理来进行代码修改和创建。 Sweep 开始搜索相关代码片段的步骤如下： 1. 使用 MPNet 嵌入和 DeepLake 向量存储，通过标题和描述在代码片段上下文中查询，并检索前 100 个片段。我们提前使用基于 CST 的自定义分块器对文件进行分块。更多关于我们的搜索基础设施的详细介绍请参见 [https://docs.sweep.dev/blogs/search-infra](https://docs.sweep.dev/blogs/search-infra) 和 [https://docs.sweep.dev/blogs/building-code-search](https://docs.sweep.dev/blogs/building-code-search)。 2. 使用基于提交次数和最新提交时间的启发式方法重新排序片段，并选取前 4 个。假设最新提交且提交次数最多的文件更有可能再次被编辑。在这一点上，我们还会添加任何直接提到的文件。 3. 对片段进行去重和融合。例如，如果获取到的片段是 main.py:0-50 和 main.py:51-100，则它们会被融合为 main.py:0-100。然后我们在每个方向上扩展每个片段 25 行，因此 main.py:25-75 变为 main.py:0-100。 4. 使用 ctag 摘要生成仓库的摘要。摘要包含重新排序后前 10 个文件的变量名和函数声明。这以目录树的形式呈现：从根目录开始一直到文件以及文件中的类、方法和变量。只有前 10 个文件的同级文件会被包含在内。 此时的最终上下文大致如下： ```bash import numpy as np ... import pytest ... ... .gitignore jp-app/ |- App.xaml |- App.xaml.cs | |- namespace jp_app | |- class App | |- method App (ISystemLanguageService systemLanguageService) | |- method OnStart () Repo name: sweepai/sweep: an AI junior dev Username: kevinlu1248 Query: Sweep: Use os agnostic temp directory for windows ``` ### Cody [How Cody understands your codebase](https://sourcegraph.com/blog/how-cody-understands-your-codebase) #### 如何在提示中使用上下文 当用户通过聊天消息或命令向 Cody 查询时，Cody 首先会编译一个 prompt。Cody 将用户的输入整理成一个提示词，以便从大型语言模型（LLM）中获取最佳响应。 提示分为三部分： 1. **前缀（Prefix）**。描述所需输出的可选说明。Cody经常使用前缀，例如，当开发人员触发一个命令时，这个命令是预定义的任务，旨在返回特定的输出格式。例如，对于"Test"命令，Cody会使用前缀来定义输出格式为单元测试。 2. **用户输入（User input）**。用户提供的查询。 3. **上下文（Context）**。Cody查找并检索的附加信息，以帮助LLM提供相关答案。 ![Prompt Construction](images/prompt-construction.png) #### 示例说明 例如，当用户触发 Cody 的 "Explain" 命令时，Cody生成的提示可能如下所示： - **前缀**： ``` Explain the following Go code at a high level. Only include details that are essential to an overall understanding of what's happening in the code. ``` - **用户输入**： ``` zoekt.QueryToZoektQuery(b.query, b.resultTypes, b.features, typ) ``` - **上下文**： ``` [Contents of sourcegraph/sourcegraph/internal/search/zoekt/query.go] ``` 这个完整的提示，包括所有三部分内容，然后被发送到 LLM。LLM 根据提示中包含的信息以及其基线模型中的信息进行工作。任何有关用户代码库的问题， 只有在上下文（作为提示的一部分发送）提供了足够的信息时，LLM 才能回答。 #### SourceGraph Cody 示例 ![Sourcegraph Cloud](images/enterprise-architecture-cloud-v2.png) #### 问答示例 1. **广泛的上下文检索**：对于聊天和命令，Cody 需要覆盖用户可能询问的整个代码库的广泛上下文。 2. **Sourcegraph 代码智能平台**：Cody 利用 Sourcegraph 的平台，该平台可以索引并理解来自多个存储库（从几个到超过10万个）的代码。 3. **搜索和上下文选择**： - **用户查询处理**：当用户调用 Cody 时，可以选择最多10个存储库。Cody会预处理用户查询，将其标记化并去除多余的信息。 - **搜索引擎**：然后，这些标记由 Sourcegraph 的搜索引擎处理，扫描选定的存储库。 - **相关性排名**：Cody 使用改进的 BM25 排名函数和其他调整过的信号，根据搜索查询的相关性对文件片段进行排名。最相关的片段会被发送回Cody。 4. **本地上下文整合**：Cody 还会整合用户 IDE 中打开文件的本地上下文，将这些与从 Sourcegraph 搜索中检索到的片段结合起来。 5. **全局排名和提示构建**：Cody 对所有片段进行全局排名，并根据长度选择最相关的片段来构建提示的上下文。这个上下文连同用户输入一起被发送到LLM（大语言模型）以生成响应。 例如，用户可能会询问：`How it auto generate test for Java?` Retrieval-based QA： ```bash Searched entire codebase for relevant files java/src/test/kotlin/cc/unitmesh/idea/java/JavaAutoProcessorTest.kt java/src/test/kotlin/cc/unitmesh/idea/java/JavaCodeProcessorTest.kt java/src/test/kotlin/cc/unitmesh/idea/java/JavaSpringCodeCreatorTest.kt java/src/test/kotlin/cc/unitmesh/idea/java/JavaParseUtilTest.kt java/src/test/kotlin/cc/unitmesh/idea/provider/JvmAutoDevFlowTest.kt src/main/resources/intentionDescriptions/DefaultDocumentationIntention/description.html java/src/test/kotlin/cc/unitmesh/idea/provider/JvmPromptStrategyTest.kt java/src/test/kotlin/cc/unitmesh/idea/java/SpringLayerCharacteristicTest.kt java/src/main/kotlin/cc/unitmesh/idea/provider/JavaTestDataBuilder.kt java/src/main/kotlin/cc/unitmesh/idea/context/JavaCodeModifier.kt webstorm/src/main/kotlin/cc/unitmesh/ide/webstorm/provider/testing/JavaScriptTestCodeModifier.kt java/src/test/kotlin/cc/unitmesh/idea/context/JavaContextCollectionUtilsKtTest.kt docs/features/auto-dev.md README.md docs/index.md ``` Here are some ways AutoDev can auto generate tests for Java code: - When you create a new Java class or method, AutoDev provides an intention action to generate a test stub. This creates a skeleton test class and methods in the test folder. - When you make changes to existing code, AutoDev analyzes the changes and suggests relevant tests to add or update via intention actions. For example, adding a new method would suggest creating a test method. - AutoDev can generate test data models based on method parameters and return types. It analyzes the code structures and provides sample test data. - For common architectures like Spring MVC, AutoDev has predefined templates to generate component tests for layers like Controllers, Services etc. - AutoDev integrates with test runners like JUnit. It can auto-run tests and if there are failures, provide quick fixes and suggestions to update tests. - The test generation works both for unit tests and integration tests. AutoDev looks at package names, configs and contexts to determine which type of tests to create. In summary, AutoDev aims to reduce manual test writing by auto generating skeletons and suggestions, analyzing contexts and architectures, and integrating with testing workflows. Let me know if you have any other questions! 中文：`AutoDev 是如何实现自动生成 Java 测试代码的？` ```bash Searched entire codebase for relevant files java/src/test/kotlin/cc/unitmesh/idea/provider/JvmAutoDevFlowTest.kt src/main/resources/prompts/openai/update_service_method.vm src/main/resources/intentionDescriptions/AutoDevIntentionHelper/description.html src/main/resources/intentionDescriptions/AutoDevIntention/description.html src/main/resources/prompts/openai/create_service_and_repository.vm plugin/description.html src/main/resources/intentionDescriptions/DefaultDocumentationIntention/description.html java/src/test/kotlin/cc/unitmesh/idea/java/JavaCodeProcessorTest.kt java/src/test/kotlin/cc/unitmesh/idea/java/JavaParseUtilTest.kt java/src/test/kotlin/cc/unitmesh/idea/java/JavaAutoProcessorTest.kt java/src/main/kotlin/cc/unitmesh/idea/flow/JvmAutoDevFlow.kt src/main/resources/prompts/openai/create_controller.vm README.md docs/features/auto-dev.md docs/index.md ``` 根据 AutoDev 的代码,它实现自动生成 Java 测试代码的主要方式是: 1. 提供一个创建测试的 Intention 动作。当在 Java 代码中调用这个 Intention 时,会触发自动生成测试代码的逻辑。 2. 在后台使用 OpenAI Codex 模型自动生成测试代码。主要流程是: - 收集当前需要测试的 Java 代码作为 Prompt。 - 向 OpenAI 提交生成测试代码的请求。 - 获取 OpenAI 返回的测试代码。 - 处理测试代码,插入到项目中合适的测试类或测试方法中。 3. 生成的测试代码会包含基本的单元测试框架代码,以及针对主代码的一些典型测试用例。 4. 生成后的测试代码还会尝试自动运行,如果测试失败,会再次请求 OpenAI 生成修复测试代码的建议。 所以整体上,AutoDev 主要通过 UI 操作触发,配合 OpenAI 自动生成代码的能力,来实现自动化测试代码的生成。 #### 问答数据流 ![Cody Chat Dataflow](images/cody-chat-dataflow.png) Cody在两种场景下的上下文构建方式不同，分别是聊天/命令和自动完成。 ##### 聊天和命令 1. **广泛的上下文检索**：对于聊天和命令，Cody 需要覆盖用户可能询问的整个代码库的广泛上下文。 2. **Sourcegraph 代码智能平台**：Cody 利用 Sourcegraph 的平台，该平台可以索引并理解来自多个存储库（从几个到超过10万个）的代码。 3. **搜索和上下文选择**： - **用户查询处理**：当用户调用 Cody 时，可以选择最多10个存储库。Cody会预处理用户查询，将其标记化并去除多余的信息。 - **搜索引擎**：然后，这些标记由 Sourcegraph 的搜索引擎处理，扫描选定的存储库。 - **相关性排名**：Cody 使用改进的 BM25 排名函数和其他调整过的信号，根据搜索查询的相关性对文件片段进行排名。最相关的片段会被发送回Cody。 4. **本地上下文整合**：Cody 还会整合用户 IDE 中打开文件的本地上下文，将这些与从 Sourcegraph 搜索中检索到的片段结合起来。 5. **全局排名和提示构建**：Cody 对所有片段进行全局排名，并根据长度选择最相关的片段来构建提示的上下文。这个上下文连同用户输入一起被发送到LLM（大语言模型）以生成响应。 ##### 自动补全 自动补全： 1. **速度和本地上下文优先**：自动补全需要非常快，优先考虑本地上下文而不是远程搜索。 2. **意图解析**：使用Tree-Sitter，Cody 解析用户的输入以确定最相关的完成体验，无论是填充函数体、编写文档字符串还是实现方法调用。 3. **本地上下文检索**：Cody 从各种本地来源（如活动文件、其他打开的标签页和最近关闭的标签页）检索上下文。 4. **上下文打包和补全**：它识别相关的代码段，将最相关的片段打包成一个提示。这提示被发送到一个针对完成任务优化的 LLM，生成的建议会作为虚拟文本显示在用户光标前。 ##### Embeddings 转变 Cody最初使用 Embeddings（高维数据的密集向量表示）来检索上下文，但由于几个缺点而放弃了： - **数据隐私**：将代码发送到 OpenAI 进行处理存在隐私问题。 - **维护复杂性**：创建和更新嵌入增加了 Sourcegraph 管理员的复杂性。 - **可扩展性**：处理大型代码库（超过10万个存储库）的嵌入非常耗费资源，限制了多存储库上下文功能的构建。 新系统利用 Sourcegraph 的本地平台，避免了这些问题，因为不需要外部处理，也不需要额外配置，并且可以更有效地扩展。然而，Embeddings 可能在未来改进中继续探索。 ### Aider - 仓库映射提供上下文 aider 的最新版本会随每个修改请求向 GPT 发送一个仓库映射。这个映射包含仓库中所有文件的列表，以及每个文件中定义的符号。像函数和方法这样的可调用对象还包括它们的签名。 - GPT 可以看到仓库中所有地方的变量、类、方法和函数签名。仅此一项可能已经为其提供了足够多的上下文来解决许多任务。例如，它可能可以仅基于映射中显示的细节来理解如何使用模块导出的 API。 - 如果需要查看更多代码，GPT 可以使用映射自行确定需要查看的文件。然后，GPT 将要求查看这些特定文件，而 aider 将自动将它们添加到对话上下文中（经过用户批准）。 当然，对于大型代码库，即使仅仅映射可能也太大了以至于超出上下文窗口的能力。然而，这种映射方法扩展了与 GPT-4 在比以往更大的代码库上合作的能力。它还减少了手动选择要添加到对话上下文中的文件的需要，使 GPT 能够自主识别与当前任务相关的文件。 #### 从 Ctags 到 TreeSitter [Improving GPT-4’s codebase understanding with ctags](https://aider.chat/docs/ctags.html) tree-sitter 仓库映射取代了 aider 最初使用的基于 ctags 的映射。从 ctags 切换到 tree-sitter 带来了许多好处： - 映射更丰富，直接显示源文件中的完整函数调用签名和其他详细信息。 - 借助 py-tree-sitter-languages，我们通过一个 python 包获得了对许多编程语言的全面支持，该包在正常的 pip 安装 aider-chat 的过程中自动安装。 - 我们消除了用户通过某些外部工具或软件包管理器（如 brew、apt、choco 等）手动安装 universal-ctags 的要求。 - Tree-sitter 集成是实现 aider 未来工作和能力的关键基础。 一些可能减少映射数据量的方法包括： - 精简全局映射，优先考虑重要符号并丢弃"内部"或其他全局不相关的标识符。可能可以借助 gpt-3.5-turbo 在灵活且与语言无关的方式中进行这种精简。 - 提供机制让 GPT 从精简的全局映射子集开始，并允许它要求查看其感觉与当前编码任务相关的子树或关键词的更多细节。 - 尝试分析用户给出的自然语言编码任务，并预测什么样的仓库映射子集是相关的。在特定的仓库内进行先前编码对话的分析可能有助于此工作。针对 chat history、仓库映射或代码库的向量和关键字搜索可能有所帮助。 一个关键目标是优先选择语言无关或可以轻松部署到大多数流行编程语言的解决方案。ctags 解决方案具有这种优势，因为它预先支持大多数流行语言。我怀疑语言服务器协议可能比 ctags 更适合这个问题。但是，对于广泛的语言，它的部署可能更为繁琐。用户可能需要为他们感兴趣的特定语言搭建一个 LSP 服务器。 ### Tabbml [Repository context for LLM assisted code completion](https://tabby.tabbyml.com/blog/2023/10/16/repository-context-for-code-completion/) 以下是提供的文本的中文总结： #### 使用语言模型（LLMs）进行编码任务： - **优势**：在独立编码任务中，如创建新的独立函数时，基于编码数据预训练的LLMs表现出色。 - **挑战**：当应用于复杂的现有代码库时，LLMs由于依赖关系和链接子系统的API而面临挑战。 #### 应对上下文挑战： - **需要上下文**：LLMs需要代码库的上下文来理解依赖关系，并生成与现有抽象相集成的代码。 - **最佳上下文传输**：由于大小限制和推理速度的限制，每个请求中发送整个代码库是不切实际的。 - **选择性上下文化**：选择性地发送相关片段（如特定函数定义）优化了提供给LLMs的上下文，避免了超载上下文窗口。 #### 高效的上下文处理： - **手动与自动上下文选择**：手动选择片段不理想；利用Tree-sitter进行索引创建和检索的自动化方法提高了效率。 - **Tree-sitter集成**：利用Tree-sitter解析和索引代码，有效提取LLMs上下文所需的相关片段。 - **片段格式**：片段格式化保持代码语义，有助于LLMs理解而不干扰现有代码。 #### 未来发展： - **增强检索和排名**：持续改进片段索引和检索算法（如注意力权重热图），旨在优化LLMs在编码任务中的效果。 - **迭代开发**：持续改进以增强LLMs在复杂代码库中提供上下文的质量和效率。 #### 结论： 该方法强调了上下文在提升LLMs在编码任务中性能方面的关键作用，平衡了全面理解的需求与上下文窗口大小和推理速度的实际限制。通过选择性提供上下文片段和利用Tree-sitter等先进解析技术，该方法旨在在复杂代码库中最大化LLMs的效用，同时最小化计算开销。 ## Continue https://github.com/continuedev/continue https://docs.continue.dev/features/codebase-embeddings Continue 会为你的代码库建立索引，以便稍后能够自动从整个工作区中提取最相关的上下文。这是通过嵌入检索和关键词搜索的组合实现的。默认情况下，所有嵌入都是在本地使用 all-MiniLM-L6-v2 计算，并存储在本地的 `~/.continue/index` 中。 目前，代码库检索功能以“codebase”和“folder”上下文提供者的形式提供。你可以通过在输入框中输入 @codebase 或 @folder 来使用它们，然后提问。输入框的内容会与代码库（或文件夹）的嵌入进行比较，以确定相关文件。 以下是一些常见的用例： - 针对你的代码库提出高级问题 - “如何向服务器添加新端点？” - “我们是否在任何地方使用了 VS Code 的 CodeLens 功能？” - “是否已有将 HTML 转换为 markdown 的代码？” - 使用现有示例生成代码 - “生成一个带有日期选择器的新 React 组件，使用现有组件的相同模式” - “使用 Python 的 argparse 为这个项目编写一个 CLI 应用程序的初稿” - “在 bar 类中实现 foo 方法，遵循其他 baz 子类中的模式” - 使用 @folder 针对特定文件夹提问，提高获得相关结果的可能性 - “这个文件夹的主要用途是什么？” - “我们如何使用 VS Code 的 CodeLens API？” - 或者使用 @folder 代替 @codebase 提出上述问题 以下是一些不适用的场景： - 当你需要 LLM 查看代码库中的每个文件时 - “查找 foo 函数被调用的所有地方” - “检查我们的代码库，找出任何拼写错误” - 重构代码 - “为 bar 函数添加一个新参数，并更新所有调用处” ## Bloop https://github.com/BloopAI/bloop bloop 是为你的代码提供支持的 ChatGPT。你可以使用自然语言提问，搜索代码，并基于现有代码库生成补丁。 工程师们通过使用 bloop 提高工作效率，包括： - 用简单的语言解释文件或功能的工作原理 - 基于现有代码编写新功能 - 理解文档不完善的开源库的使用方法 - 精确定位错误 - 使用其他语言提问关于英文代码库的问题 - 通过检查现有功能减少代码重复 功能特点 - 基于 AI 的对话式搜索 - Code Studio，一个使用你代码作为上下文的 LLM（大语言模型）游乐场 - 超快速的正则表达式搜索 - 同步本地和 GitHub 仓库 - 高级查询过滤器，可以缩小搜索结果范围 - 使用符号搜索查找函数、变量或特性 - 精确的代码导航（跳转到引用和定义），支持 10 多种最流行的语言，基于 Tree-sitter 构建 - 注重隐私的设备端嵌入，用于语义搜索 ## 其它相关论文 ### [CodePlan: Repository-level Coding using LLMs and Planning](https://arxiv.org/abs/2309.12499) 软件工程活动，如软件包迁移、修复静态分析或测试中的错误报告，以及向代码库添加类型注解或其他规范，涉及广泛编辑整个代码库。 我们将这些活动称为代码库级别的编码任务。像 GitHub Copilot 这样的最近工具，由大型语言模型（LLMs）驱动，已成功地为局部编码问题提供了高质量的解决方案。代码库级别的编码任务更为复杂，不能直接使用 LLMs 解决，因为代码库内部相互依赖，并且整个代码库可能太大而无法适应输入。我们将代码库级别的编码视为一个规划问题，并提出了一个与任务无关的神经 符号框架CodePlan来解决它。CodePlan 综合了多步骤的编辑链（计划），其中每一步都会调用LLM处理来自整个代码库、先前代码更改和任务特定指令的上下文信息。 CodePlan 基于增量依赖分析、变更影响分析和自适应规划算法（符号组件）与神经 LLMs 的创新结合。我们评估了 CodePlan 在两个代码库级别任务上的有效性： 软件包迁移（C#）和时间相关的代码编辑（Python）。每个任务在多个代码库上进行评估， 每个代码库都需要对许多文件进行相互依赖的更改（2 至 97 个文件之间）。 以往没有使用 LLMs 自动化处理这种复杂程度的编码任务。我们的结果显示，与基准相比，CodePlan 与实际情况更匹配。CodePlan 能够使 5/7 个代码库通过有效性检查（即无错误地构建并进行正确的代码编辑），而基准（没有规划但具有与 CodePlan 相同类型的上下文信息）则无法使任何一个代码库通过检查 。 我们在https://github.com/microsoft/codeplan 提供了我们的（非专有）数据、评估脚本和补充材料。 ================================================ FILE: src/agent-coding-task.md ================================================ # 编码任务 Agent ## 示例 ### CodexGraph [CodexGraph](https://github.com/modelscope/modelscope-agent/tree/master/apps/codexgraph_agent) ![](images/codexgraph_motivation.png) 大型语言模型（LLMs）在独立的代码任务（如HumanEval和MBPP）方面表现出色，但在处理整个代码库方面存在困难。这个挑战促使研究人员在代码库规模上增强 LLM-代码库交互的研究。目前的解决方案依赖于基于相似性的检索或手动工具和API，每种方法都有明显的缺点。基于相似性的检索在复杂任务中通常具有低召回率， 而手动工具和API通常是特定于任务的，需要专业知识，降低了它们在不同代码任务和实际应用中的通用性。为了缓解这些限制，我们介绍了\framework， 这是一个将LLM代理与从代码库中提取的图数据库接口集成的系统。通过利用图数据库的结构属性和图查询语言的灵活性，\framework使LLM代理能够构建和执行查询， 从而实现精确的、代码结构感知的上下文检索和代码导航。我们使用三个基准测试评估了\framework：CrossCodeEval、SWE-bench和EvoCodeBench。 此外，我们开发了五个真实的编码应用程序。通过一个统一的图数据库模式，\framework在学术和实际环境中展示了竞争性能和潜力，展示了它在软件工程中的多样性和功效。 我们的应用演示：https://github.com/modelscope/modelscope-agent/tree/master/apps/codexgraph_agent。 ================================================ FILE: src/agent-copilot-workspace.md ================================================ # 编码智能体分析：Copilot Workspace ## 示例 ### Copilot Workspace 提示词示例： 对应的 Workspace 构建过程如下： ```markdown 1. Deciding which workspace information to collect 2. Determining workspace structure… 3. Asking the model to update the user question and provide queries… - keywords - workspaceChunkIndex 4. Running all tools… - xxxx 5. Collecting workspace information ``` 模型策略： ```markdown 2024-04-15 11:46:05.940 [info] [chat fetch] url https://api.githubcopilot.com/chat/completions 2024-04-15 11:46:05.940 [info] [chat fetch] modelMaxPromptTokens 3072 2024-04-15 11:46:05.940 [info] [chat fetch] modelMaxResponseTokens 4096 2024-04-15 11:46:05.940 [info] [chat fetch] chat model gpt-4 2024-04-15 11:46:07.735 [info] [chat fetch] request.response: [https://api.githubcopilot.com/chat/completions], took 1795 ms 2024-04-15 11:46:19.135 [info] [streamMessages] message 0 returned. finish reason: [stop] 2024-04-15 11:46:19.136 [info] [streamChoices] request done: requestId: [xxx] responseId: xxx] model deployment ID: [] 2024-04-15 11:46:19.153 [info] [chat fetch] url https://api.githubcopilot.com/chat/completions 2024-04-15 11:46:19.153 [info] [chat fetch] modelMaxPromptTokens 7168 2024-04-15 11:46:19.153 [info] [chat fetch] modelMaxResponseTokens 4096 2024-04-15 11:46:19.153 [info] [chat fetch] chat model gpt-3.5-turbo 2024-04-15 11:46:19.785 [info] [chat fetch] request.response: [https://api.githubcopilot.com/chat/completions], took 631 ms 2024-04-15 11:46:19.785 [info] [streamMessages] message 0 returned. finish reason: [stop] 2024-04-15 11:46:19.786 [info] [streamChoices] request done: requestId: [xxx] responseId: [xxx] model deployment ID: [x4dff5e5d11fc] ``` #### 理解阶段提示词 ```markdown You are a coding assistant who helps the user answer questions about code in their workspace by providing a list of relevant keywords they can search for to answer the question. The user will provide you with potentially relevant information from the workspace. This information may be incomplete. DO NOT ask the user for additional information or clarification. DO NOT try to answer the user's question directly. **Additional Rules** Think step by step: 1. Read the user's question to understand what they are asking about their workspace. 2. If the question contains pronouns such as 'it' or 'that', try to understand what the pronoun refers to by looking at the rest of the question and the conversation history. 3. If the question contains an ambiguous word such as 'this', try to understand what it refers to by looking at the rest of the question, the user's active selection, and the conversation history. 4. Output a precise version of the question that resolves all pronouns and ambiguous words like 'this' to the specific nouns they stand for. Be sure to preserve the exact meaning of the question by only changing ambiguous pronouns and words like 'this'. 5. Then output a short markdown list of up to 8 relevant keywords that the user could try searching for to answer their question. These keywords could be used as file names, symbol names, abbreviations, or comments in the relevant code. Put the most relevant keywords to the question first. Do not include overly generic keywords. Do not repeat keywords. 6. For each keyword in the markdown list of related keywords, if applicable add a comma-separated list of variations after it. For example, for 'encode', possible variations include 'encoding', 'encoded', 'encoder', 'encoders'. Consider synonyms and plural forms. Do not repeat variations. **Examples** User: Where's the code for base64 encoding? Response: Where's the code for base64 encoding? - base64 encoding, base64 encoder, base64 encode - base64, base 64 - encode, encoded, encoder, encoders ``` ### 使用Copilot Workspace的实现步骤 [Copilot Workspace: What It Is, How It Works, Why It Matters](https://zilliz.com/blog/what-is-copilot-workspace-and-why-it-matters) 以下是如何利用 Copilot Workspace 来实现该功能的方法： 1. **任务创建**：首先创建一个GitHub issue，任务是将应用程序改为多语言版本。具体任务是将(BGE-M3)多语言模型集成到现有的RAG系统中。 2. **规范**：Copilot Workspace分析任务并生成高级规范，确定需要更新数据处理管道以处理多种语言，并修改RAG系统以利用BGE-M3提供多语言支持。 3. **规划**：Workspace接着生成详细的计划。包括以下步骤： - 更新数据摄取过程以包含多语言数据。 - 修改现有的Milvus设置以支持BGE-M3。 - 调整RAG系统以利用BGE-M3的多语言功能。 - 测试系统以确保其能够支持多种语言。 4. **编码**：基于验证后的计划，Copilot Workspace生成必要的代码： - 更新数据摄取脚本以预处理和索引多语言数据到Milvus中。 - 配置Milvus代码以使用BGE-M3嵌入进行多语言的相似性搜索。 - 修改RAG系统以使用多语言模型查询Milvus并检索相关结果。 5. **审查和测试**：审查生成的代码，进行必要的调整并测试更改。 6. **拉取请求和合并**：满意后，打开一个拉取请求与团队审查更改。最终验证后，合并更改，使应用程序支持多语言功能。 ================================================ FILE: src/agent-data-security.md ================================================ # 编码智能体：RAG 数据与 AI 安全 在当今的数字化时代，数据安全和隐私保护已成为科技发展的重中之重。随着人工智能技术的飞速发展，如何确保数据在智能体处理过程中的安全性，成为了一个亟待解决的问题。 本文将探讨编码智能体在处理RAG（检索增强生成）数据时，如何保障AI安全，并通过几个具体案例来阐述。 ## 经验示例 ### 示例 1：GitHub Secret 在GitHub中，开发者有时会不小心将敏感信息如API密钥等提交到代码仓库中。以下是一个示例，展示了GitHub如何检测并阻止包含敏感信息的push操作： ```bash Current branch main is up to date. Enumerating objects: 32, done. Counting objects: 100% (32/32), done. Delta compression using up to 16 threads Compressing objects: 100% (16/16), done. Writing objects: 100% (19/19), 4.59 KiB | 1.15 MiB/s, done. Total 19 (delta 10), reused 0 (delta 0), pack-reused 0 (from 0) remote: Resolving deltas: 100% (10/10), completed with 7 local objects. remote: error: GH013: Repository rule violations found for refs/heads/main. remote: remote: - GITHUB PUSH PROTECTION remote: ————————————————————————————————————————— remote: Resolve the following violations before pushing again remote: remote: - Push cannot contain secrets remote: remote: remote: (?) Learn how to resolve a blocked push remote: https://docs.github.com/code-security/secret-scanning/pushing-a-branch-blocked-by-push-protection remote: remote: remote: —— OpenAI API Key ———————————————————————————————————— remote: locations: remote: - commit: 620252f31718c63dbc6c89d0c0b989187489ef1c remote: path: docs/guarding/pipeline-guarding.md:34 remote: - commit: bb7952d77a7c76a4d29c97bb049af3e709d543f0 remote: path: docs/guarding/pipeline-guarding.md:34 remote: - commit: bb7952d77a7c76a4d29c97bb049af3e709d543f0 remote: path: shirelang/src/test/kotlin/com/phodal/shirelang/ShirePatternPipelineTest.kt:116 remote: remote: (?) To push, remove secret from commit(s) or follow this URL to allow the secret. remote: https://github.com/phodal/shire/security/secret-scanning/unblock-secret/xxx remote: remote: remote: ``` 此示例显示了GitHub的push保护机制如何检测到代码中包含的OpenAI API密钥，并阻止了push操作，同时提供了如何解决这一问题的指南。 ## 示例 ### Unkey Semantic Cache - [Code](https://github.com/unkeyed/unkey/tree/main/apps/semantic-cache) - [https://www.unkey.com/blog/semantic-caching](https://www.unkey.com/blog/semantic-caching) 在处理自然语言查询时，一个简单的缓存策略是将用户的查询作为键，将工作流的结果作为值。但这种方法有一个缺点，即它依赖于用户查询的表述完全相同。 为了解决这个问题，语义缓存应运而生。以下两张图表展示了缓存命中和缓存未命中的情况： ![unkey-cachehit.webp](images/unkey-cachehit.webp) ![unkey-cachemiss.webp](images/unkey-cachemiss.webp) 通过基于查询嵌入的缓存，语义缓存确保即使查询的表述不同，只要意图相同，用户就能命中缓存。 ## Microsoft Presidio Presidio是一个由Microsoft开发的工具，旨在帮助组织快速识别和匿名化敏感数据。它能够处理文本和图像中的各种敏感信息，如信用卡号码、姓名、位置等。 ![presidio-analyze-anonymize.png](images/presidio-analyze-anonymize.png) ![presidio-ner-flow.png](images/presidio-ner-flow.png) Presidio分析器是一个基于Python的服务，用于检测文本中的PII（个人身份信息）实体。它运行一组不同的PII识别器，每个识别器负责使用不同的机制检测一个或多个PII实体。 ## SkyFlow https://www.skyflow.com/product/llm-privacy-vault ![](images/skyflow-llm-privacy-vault.png) ### Protect AI [LLM Guard](https://llm-guard.com/) Supported scanners ![](images/LLMGuard-features.webp) Prompt scanners - Anonymize，acts as your digital guardian, ensuring your user prompts remain confidential and free from sensitive data exposure. - BanCode，is designed to detect and ban code in the prompt. - BanCompetitors, scanner is designed to prevent the inclusion of competitor names in the prompts submitted by users. This scanner ensures that prompts containing references to known competitors are either flagged or altered, according to user settings, to maintain a strict focus on the user's own products or services. - BanSubstrings, Ensure that specific undesired substrings never make it into your prompts with the BanSubstrings scanner. - BanTopics, designed to restrict specific topics, such as religion, violence, from being introduced in the prompt using Zero-Shot classifier. - Code, is designed to detect and validate code in the prompt.It can be particularly useful in applications that need to accept only code snippets in specific languages. - Gibberish, is designed to identify and filter out gibberish or nonsensical inputs in English language text. It proves invaluable in applications that require coherent and meaningful user inputs, such as chatbots and automated processing systems. - InvisibleText, is designed to detect and remove non-printable, invisible Unicode characters from text inputs. This is crucial for maintaining text integrity in Large Language Models (LLMs) and safeguarding against steganography-based attacks. - Language, identifies and assesses the authenticity of the language used in prompts. - PromptInjection, specifically tailored to guard against crafty input manipulations targeting large language models ( LLM). By identifying and mitigating such attempts, it ensures the LLM operates securely without succumbing to injection attacks. - Regex, is designed to sanitize prompts based on predefined regular expression patterns. It offers flexibility in defining patterns to identify and process desirable or undesirable content within the prompts. - Secrets, diligently examines user inputs, ensuring that they don't carry any secrets before they are processed by the language model. - Sentiment, scans and evaluates the overall sentiment of prompts using the SentimentIntensityAnalyzer from the NLTK ( Natural Language Toolkit) library. - TokenLimit, ensures that prompts do not exceed a predetermined token count, helping prevent resource-intensive operations and potential denial of service attacks on large language models (LLMs). - Toxicity, provides a mechanism to analyze and mitigate the toxicity of text content, playing a crucial role in maintaining the health and safety of online interactions. This tool is instrumental in preventing the dissemination of harmful or offensive content. Output scanners - BanCompetitors, is designed to identify and handle mentions of competitors in text generated by Large Language Models (LLMs). This scanner is essential for businesses and individuals who wish to avoid inadvertently promoting or acknowledging competitors in their automated content. - BanSubstrings, scanner provides a safeguard mechanism to prevent undesired substrings from appearing in the language model's outputs. - BanTopics, is designed to detect outputs that touch upon topics that are considered sensitive using Zero-Shot classifier. - Bias, is designed to inspect the outputs generated by Language Learning Models (LLMs) to detect and evaluate potential biases. Its primary function is to ensure that LLM outputs remain neutral and don't exhibit unwanted or predefined biases. - Code, can be particularly useful in applications that need to accept only code snippets in specific languages. - Deanonymize, helps put back real values in the model's output by replacing placeholders. - JSON, dentifies and validates the presence of JSON structures within given outputs, and returns a repaired JSON if possible. - Language, identifies and assesses the authenticity of the language used in outputs. - LanguageSame, evaluates and checks if the prompt and output are in the same language. - MaliciousURLs, detects URLs in the output and analyzes them for harmfulness, such as detecting phishing websites. - NoRefusal, specifically designed to detect refusals in the output of language models. It can be especially useful to detect when someone is trying to force the model to produce a harmful output. - ReadingTime, estimates and manages the reading time of text content. It is particularly useful for applications where content length and reading time need to be controlled, such as in educational materials or time-sensitive reading platforms. - FactualConsistency,is designed to assess if the given content contradicts or refutes a certain statement or prompt. It acts as a tool for ensuring the consistency and correctness of language model outputs, especially in contexts where logical contradictions can be problematic. - Gibberish, is tailored to assess the outputs generated by LLMs to identify and flag gibberish or nonsensical content. Its key role is to ensure that LLM outputs are coherent and intelligible, devoid of meaningless or random text sequences. - Regex, is designed to sanitize outputs based on predefined regular expression patterns. It offers flexibility in defining patterns to identify and process desirable or undesirable content within the outputs. - Relevance,ensures that output remains relevant and aligned with the given input prompt. By measuring the similarity between the input prompt and the output, the scanner provides a confidence score, indicating the contextual relevance of the response. - Sensitive,serves as your digital vanguard, ensuring that the language model's output is purged of Personally Identifiable Information (PII) and other sensitive data, safeguarding user interactions. - Sentiment, is designed to scan and assess the sentiment of generated outputs. It leverages the SentimentIntensityAnalyzer from the NLTK (Natural Language Toolkit) library to accomplish this. - Toxicity, designed to assess the toxicity level of the content generated by language models, acting as a safeguard against potentially harmful or offensive output. - URLReachability, identifies URLs in the text and checks them for accessibility, ensuring that all URLs are reachable and not broken. ================================================ FILE: src/agent-debug.md ================================================ # Agent 调试 ## Prompt（提示词） 测试 ### Prompt 单元测试 > 验证智能体内部的一个小部分，例如验证智能体在明显的情况下调用了特定的工具。适合测试晦涩的场景，容易验证预期行为。 ### Prompt 集成测试 > 从头到尾的复杂场景。这更有价值，因为它能告诉你“它实际上是否有效”。但这往往难以编写断言，因为结果是模糊的，例如对一个模棱两可的问题的回答。 ## 示例 ### Ellipsis [Lessons from 15 months of building LLM agents](https://www.ellipsis.dev/blog/lessons-from-15-months-of-building-llm-agents) - 评估与测试：作者强调了评估（evals）在开发LLM代理过程中的重要性。评估有两种类型：单元测试和集成测试。单元测试检查代理的某个小部分，而集成测试则验证复杂场景的整体表现。由于提示词（prompts）非常脆弱，甚至一个小的修改都可能导致输出质量下降，因此反复测试和验证是确保代理成功的关键。 - 快照与缓存：为了应对LLM的非确定性和高成本，作者建议在开发代理时设置缓存。缓存不仅能使测试结果更具确定性，还能显著加快速度并降低成本。 - 可观测性与日志记录：作者指出，尽管有许多高级的观测工具，但他仍然发现传统的日志记录更为有用。日志记录能够帮助开发者直观地理解代理的行为并诊断问题。 - 提示词的管理与优化：作者认为提示词必须在版本控制中进行管理，尤其是对于复杂的代理而言。此外，他认为现有的LLM代理构建库（如Langchain）在实际应用中并不实用，代理往往需要大量的定制，因此自己编写代理逻辑可能更加高效。 ### PromptLayer https://promptlayer.com/ PromptLayer不仅仅是一个调试工具，它还是一个强大的提示工程和管理平台，提供了多种关键功能，使得AI应用的开发和运营变得更加高效和智能化。 1. **提示工程与管理**：PromptLayer提供了强大的提示版本控制、批量处理和调试工具，使得团队能够更快地迭代和优化提示，确保AI模型能够提供更准确和上下文相关的响应。 2. **可观察性与分析**：通过详细的日志和元数据分析，PromptLayer帮助团队更好地理解AI的行为模式，发现潜在的问题并及时进行优化，减少了AI系统中的“黑箱”操作，增强了透明度。 3. **可视化编辑与部署**：PromptLayer的可视化编辑和自动部署功能，使得即使是非技术团队也能够高效地进行提示工程。这减少了对工程资源的依赖，提升了团队的整体生产力和灵活性。 #### PromptLayer 案例 案例： | **公司名称** | **挑战** | **PromptLayer解决方案** | **结果** | |---------------|--------------------------------|----------------------------------------------|----------------------------------| | **Ellipsis** | 快速扩展带来的高请求量导致调试效率低下 | 使用PromptLayer的可观察性平台和元数据搜索功能，快速定位问题并通过UI进行调试 | 调试时间减少90%，调试步骤减少90%，避免了大量工程资源消耗 | | **ParentLab** | 内容和工程团队需要快速迭代和部署AI提示 | 通过PromptLayer的CMS和可视化编辑功能，简化提示迭代和部署流程 | 提示部署速度提升10倍，节省400多个工程小时，提示质量显著提高 | | **Speak.com** | 非技术团队需独立迭代AI功能，但缺乏工程支持 | 使用PromptLayer，内容和业务团队可以自主进行提示工程，减少开发时间 | 产品开发和国际扩张中的大量时间和成本节省，关键功能迭代更快速灵活 | | **ParentLab** | 需要分析用户行为和优化AI响应，但Notion数据库效率低下 | PromptLayer提供日志和分析功能，帮助理解用户行为并持续改进AI响应 | 提示迭代次数增加10倍，提示质量显著提高，节省数百个工程小时 | #### Prompt Router - [Prompt Routers and Modular Prompt Architecture](https://blog.promptlayer.com/prompt-routers-and-modular-prompt-architecture-8691d7a57aee/) ![](images/prompt-router.png) 有诸多方法可以编程决定将用户的消息路由至哪个提示。 1. 通用大型语言模型（LLM）：最简单且最常见的方法是使用如GPT-4这样的大型语言模型。以下我们会采用这种方法。简而言之，创建一个提示模板，该模板接收用户消息，并返回用于路由的提示模板。 2. 微调模型：通常，如果您能够可靠地获得GPT-4提示作为路由器，您可以微调一个较小的模型以节省成本和延迟。尝试对您的GPT-4输出进行GPT-3.5-Turbo的微调。 3. 向量距离：生成嵌入向量非常快速且成本低廉（与常规完成相比）。您可以通过比较用户消息与可能分类的向量距离，轻松构建一个提示路由器。 4. 确定性方法：有时您可以通过确定性解决方案来决定如何路由。也许您正在字符串中搜索一个关键词…… 5. 传统机器学习：最后但同样重要的是，分类是传统机器学习非常常见的一个应用场景。像决策树这样的工具可以帮助您构建比通用大型语言模型更便宜、更快速的提示路由器。 为了简化，我们将使用第一种选项，并为GPT-4编写一个作为路由器的提示。我们的提示模板将接收一个用户问题，并返回一个单词，指示适当的分类：“自我”、“新闻”或“编程”。在您的应用程序代码中，您可以使用这个输出来将问题映射到相应的提示模板。 #### Prompt 管理 - [Scalable Prompt Management and Collaboration](https://blog.promptlayer.com/scalable-prompt-management-and-collaboration/) 这篇文章强调了在使用大型语言模型（LLM）开发AI产品时，提示管理的重要性。文章指出，尽管提示是使基于LLM的产品有效运行的关键，但往往被忽视， 导致产品演进过程中出现效率低下和瓶颈问题。 1. **将提示与代码分离**：将提示与主代码库分离存储，可以加快迭代速度，并使非技术人员更容易参与协作。使用提示管理系统（如PromptLayer）有助于简化这一过程。 2. **模块化设计**：文章借鉴了软件开发中的原则，建议将提示模块化为可重用的组件，如系统消息前言、少样本示例和指令。这种模块化方法简化了提示管理，使非技术人员更易参与。 3. **工作区组织**：保持提示在文件夹中的有序组织和控制访问，对于维护整洁高效的工作流程至关重要。良好的组织减少了风险，增强了协作效率。 4. **协作策略**：有效的提示管理需要建立编辑权限控制机制和版本冻结，以确保工程师与非技术人员之间的协作既稳定又安全。 #### A/B Testing Prompts Prompt AB Test ![](images/prompt-ab-test.png) 那么，究竟如何进行提示语的A/B测试呢？ - 首先，从小规模开始：先将新版本的提示语推向一小部分用户，例如5-10%的用户，或者仅仅是免费层级的客户。这样做可以限制风险，同时还能为您提供有价值的数据。 - 逐步增加：在慢慢提高推广百分比的同时，密切关注用户指标。目标可以是10%、20%、40%，最终达到100%。注意任何红旗警告或负面影响。 - 细分用户：并非所有用户都相同。考虑根据用户类型（免费用户与付费用户）、用户ID或公司等因素进行用户细分。这可以让您在全面推广之前，针对特定群体测试新版本。 - 多种方法结合：A/B测试很有力，但不要仅限于此。将其与合成在线评估和严格的线下测试结合，以全面了解提示语的表现。 - 迭代和优化：A/B测试是一个持续的过程。分析您的结果，对提示语进行调整，然后再次运行测试。持续的迭代是🗝️打造顶级提示语的关键。 关键在于要有条不紊、以数据为驱动，并且勇于尝试。通过从小规模开始，细分用户，通过对实际指标的测试和迭代，他可以充分发挥A/B测试在提示优化方面的潜力。 ================================================ FILE: src/agent-for-aise.md ================================================ # 编码智能体辅助软件工程 ## 形态 ### 16x [16x Prompt](https://prompt.16x.engineer/) 示例： ![](images/16x-prompt.webp) ### [Webwright](https://github.com/MittaAI/webwright) : Shell 增强 ```mermaid graph TD A[User] -->|Enters command| B[Webwright Shell] B -->|Processes command| E{OpenAI or Anthropic?} E -->|OpenAI| F[OpenAI API] E -->|Anthropic| G[Anthropic API] F -->|Response| H[Process AI Response] G -->|Response| H H <-->|Query/Update| L[(Vector Store)] H <-->|Query/Update| M[(Set Store)] H -->|Generate Code/App| I[Code/Application Output] H -->|Execute Function| J[Function Execution] J -->|Result| K[Process Function Result] K -->|Update Context| B I -->|Display to User| A B <-->|API Calls| N[mitta.ai API] N -->|Document Processing| O[Process Documents] N -->|Web Crawling| P[Crawl Websites] N -->|Other Functionality| Q[...] ``` ### Auto Wiki https://wiki.mutable.ai/ [Auto Wiki v2](https://blog.mutable.ai/p/auto-wiki-v2) ### CrawAI https://github.com/crewAIInc/crewAI - 基于角色的智能体设计：可定制具有特定角色、目标和工具的智能体。 - 自主智能体间委托：智能体能够自主地委托任务并在彼此间进行询问，从而提高问题解决效率。 - 灵活的任务管理：定义任务并使用可定制工具，动态分配给智能体。 - 流程驱动：目前支持顺序任务执行和分层流程，正在开发更复杂的流程，如共识和自主流程。 - 将输出保存为文件：可以保存单个任务的输出为文件，以便后续使用。 - 输出解析为 Pydantic 或 JSON：如需，可将单个任务的输出解析为 Pydantic 模型或 JSON。 - 兼容开源模型：可使用 Open AI 或开源模型运行您的团队。参考“连接 crewAI 到 LLMs”页面，了解如何配置智能体与模型之间的连接，甚至包括本地运行的模型！ ![](images/crewAI-mindmap.png) ## 示例 ### Builder.io [Introducing Micro Agent: An (Actually Reliable) AI Coding Agent](https://www.builder.io/blog/micro-agent) ![Micro Agent](images/micro-agent.webp) **Micro Agent** 是一种生成式 AI 工具，通过聚焦于特定任务并通过单元测试提供清晰的确定性反馈来创建代码。以下是其工作流程的细分： 1. **描述你的函数**：你提供一个关于所需函数的自然语言描述。 2. **AI 生成测试**：基于你的描述，Micro Agent 创建定义函数预期行为的单元测试，包括多个输入输出场景。 3. **AI 编写代码**：使用大型语言模型（LLMs）的能力，Micro Agent 编写代码（支持 JavaScript、TypeScript、Python 或其他语言）以通过生成的测试。 4. **自动迭代**：如果初始代码未能通过任何测试，Micro Agent 会反复编辑源代码并重新运行测试，直到所有测试都通过。这确保了最终代码符合指定要求。 ### 主要优势 - **更高的保证**：生成的代码更可靠，能够满足指定的要求，因为它通过了确定性的测试。 - **简化的开发过程**：自动化的迭代过程有助于高效地创建高质量代码，节省时间并提高结果的信心。 ### Codium: Cover-Agent && PR-Agent [CodiumAI Cover Agent](https://github.com/Codium-ai/cover-agent) aims to help efficiently increasing code coverage, by automatically generating qualified tests to enhance existing test suites. Below is the roadmap of planned features, with the current implementation status: * Automatically generates unit tests for your software projects, utilizing advanced AI models to ensure comprehensive test coverage and quality assurance. (similar to Meta) * Being able to generate tests for different programming languages * Being able to deal with a large variety of testing scenarios * Generate a behavior analysis for the code under test, and generate tests accordingly * Check test flakiness, e.g. by running 5 times as suggested by TestGen-LLM * Cover more test generation pains * Generate new tests that are focused on the PR changeset * Run over an entire repo/code-base and attempt to enhance all existing test suites * Improve usability * Connectors for GitHub Actions, Jenkins, CircleCI, Travis CI, and more * Integrate into databases, APIs, OpenTelemetry and other sources of data to extract relevant i/o for the test generation * Add a setting file ### Factory.ai：化繁为简 软件开发包含一系列的任务及子任务，诸如于： - 依赖编码规范、框架知识、架构设计、安全指标等进行代码编写 ![https://www.factory.ai/ 示例](images/factory-ai.svg) 如何结合 AI 更好进行知识管理，简化为项目、编码、测试、检视、文档等步骤，实现从想法到产品的快速迭代？ ![简化](images/simplify-factory-ai.svg) ### Cursor：Shadow Workspace [Shadow Workspace: Iterating on Code in the Background](https://www.cursor.com/blog/shadow-workspace) Shadow Workspace 设计标准。我们希望 Shadow Workspace 能实现以下目标： 1. LSP 可用性：AI 应该能够看到他们更改后的 lint 提示，能够跳转到定义，并且更广泛地与语言服务器协议 (LSP) 的所有部分进行交互。 2. 可运行性：AI 应该能够运行他们的代码并查看输出。 我们最初专注于 LSP 可用性。 这些目标应满足以下要求： 1. 独立性：用户的编码体验必须不受影响。 2. 隐私性：用户的代码应是安全的（例如，所有代码都保存在本地）。 3. 并发性：多个 AI 应该能够同时进行工作。 4. 通用性：应适用于所有语言和所有工作区设置。 5. 可维护性：代码应尽可能少且易于隔离。 6. 速度：任何地方都不应有分钟级的延迟，并且应有足够的吞吐量以支持数百个 AI 分支。 其中许多反映了为超过十万用户构建代码编辑器的现实情况，我们确实不希望对任何人的编码体验产生负面影响。 问题： ![问题](images/cursor-lints-example2.webp) 实现： ![Shadow Workspace](images/cursor-shadow-lint.webp) 1. AI 提议对文件进行编辑。 2. 编辑从普通窗口的渲染进程发送到其扩展宿主，然后传送到 Shadow window 的扩展宿主，最后传送到 Shadow window 的渲染进程。 3. 编辑在 Shadow window 中应用， Shadow window是隐藏且独立于用户的，所有 lint 提示都以相同的方式发送回来。 4. AI 接收到 lint 提示，并决定如何进行迭代。 #### shadow_workspace.proto https://gist.github.com/arvid220u/b976c87c7ec9f6f66595dc0ebc0f07d6 ```proto syntax = "proto3"; package aiserver.v1; option go_package = "github.com/anysphere/everysphere/schema/aiserver/v1"; service ShadowWorkspaceService { rpc GetLintsForChange(GetLintsForChangeRequest) returns (GetLintsForChangeResponse) {} rpc ShadowHealthCheck(ShadowHealthCheckRequest) returns (ShadowHealthCheckResponse) {} } message ShadowHealthCheckRequest {} message ShadowHealthCheckResponse {} // only lints in the supplied files are returned // // note that this only returns lints that were changed! unless `get_all_lints_not_just_delta_lints_for_range_in_final_model` is set message GetLintsForChangeRequest { repeated File files = 1; message File { string relative_workspace_path = 1; // the "change" we are getting lints for is the implicit delta between `initial_content` and `final_content` string initial_content = 2; string final_content = 3; // for any lints in the final model that are inside one of these ranges, we return it regardless of whether it existed in the initial model too optional RangeCollection get_all_lints_not_just_delta_lints_for_ranges_in_final_model = 4; message RangeCollection { repeated IRange ranges = 1; } // simply corresponds to vscode's irange message IRange { // 1-indexed int32 start_line_number = 1; // 1-indexed int32 start_column = 2; // 1-indexed // inclusive int32 end_line_number = 3; // 1-indexed int32 end_column = 4; } } // quick fixes will be returned for each lint. potentially a little bit slower bool include_quick_fixes = 2; // if a new file is not created, some tools will report inaccurate or incomplete lints (e.g., the typescript language server won't properly detect which tsconfig is the right one) // the temporarily created file will have a .shadowworkspace-uuid.ts extension, to reduce the chance of conflicts // the hope is that it won't affect the user, but it may, so therefore this is off by default for now // once we have a proper proxy folder structure, then this should hopefully be obsolete // WARNING: this can cause problems for the user!!! (our yarn watch breaks when new files are added and deleted, for example) // do not run this for real users! before we have the proxy folder set up bool do_not_use_in_prod_new_files_should_be_temporarily_created_for_increased_accuracy = 3; } message GetLintsForChangeResponse { repeated Lint lints = 1; message Lint { string message = 1; string severity = 2; string relative_workspace_path = 3; // the position refers to the position in the `final_content` model int32 start_line_number_one_indexed = 4; int32 start_column_one_indexed = 5; int32 end_line_number_inclusive_one_indexed = 6; int32 end_column_one_indexed = 7; message QuickFix { message Edit { string relative_workspace_path = 1; string text = 2; int32 start_line_number_one_indexed = 3; int32 start_column_one_indexed = 4; int32 end_line_number_inclusive_one_indexed = 5; int32 end_column_one_indexed = 6; } string message = 1; string kind = 2; bool is_preferred = 3; // TODO: this edit can also be a file edit in vscode! currently, we ignore those, and only include text edits repeated Edit edits = 4; } // only included if `include_quick_fixes` is true repeated QuickFix quick_fixes = 9; } } ``` ## 其它 ### 相关材料 开源自主 AI Agent 汇总 伴随 LLM 的快速发展，以 LLM 为大脑的 Agents 能力也越来越强，它们能结合规划、记忆和工具使用，来让 LLM 具备丰富的行动能力。 关于 Autonomous Agents LLM Powered Autonomous Agents via Lilian Weng https://lilianweng.github.io/posts/2023-06-23-agent/… 今天我们一起看看都有哪些开源 Agent 项目值得参考 以下是整理好的表格： | 项目名称 | 开发者 | Stars | 描述 | 链接 | |----------|----------------|-------|--------------------------------------------------------------------------|------------------------------------------------------------| | AutoGPT | @SigGravitas | 164k | 基于 LLM 的通用 Agent 框架，可以自主完成简单任务。四个重要组件：Agent、Benchmark、Forge、Frontend。 | [AutoGPT](https://github.com/Significant-Gravitas/AutoGPT) | | BabyAGI | @yoheinakajima | 19.7k | BabyAGI 能够根据给定的目标生成并执行任务，运用了来自 OpenAI、Pinecone、LangChain 和 Chroma 的前沿技术。 | [BabyAGI](https://github.com/yoheinakajima/babyagi) | | SuperAGI | @_superAGI | 15k | SuperAGI 框架提供了一个开放源代码的平台，用于创建、控制与执行 Autonomous Agents，增强 Agents 的功能性。 | [SuperAGI](https://github.com/TransformerOptimus/SuperAGI) | | AutoGen | @pyautogen | 28.3k | AutoGen 是一个开源编程框架，用于构建 AI Agents 并促进多个 Agents 间的协作以解决任务。 | [AutoGen](https://github.com/microsoft/autogen) | | MetaGPT | @AlexanderWu0 | 41.6k | MetaGPT 是一个 Multi-Agents 框架，分配不同的角色给 LLM，形成一个协同实体，以应对复杂的任务。 | [MetaGPT](https://github.com/geekan/MetaGPT) | | CamelAI | @CamelAIOrg | 4.8k | CAMEL 是一个专为研究自主与交流型 Agent 而设计的开源库，推进领域研究多种类型的 Agents、任务、提示、模型和模拟环境。 | [CamelAI](https://github.com/camel-ai/camel) | | Dify | @dify_ai | 37.1k | Dify 是一个开源 LLM 应用开发平台，结合 AI 工作流、RAG 管道、Agent 能力、模型管理、可观察性功能等。 | [Dify](https://github.com/langgenius/dify) | | CrewAI | @crewAIInc | 17.1k | 用于协调角色扮演、Autonomous Agents 的尖端框架，促进协作智能，解决复杂任务。 | [CrewAI](https://github.com/joaomdmoura/crewai/) | | Botpress | @getbotpress | 12.2k | Botpress 构建由 OpenAI GPT 提供支持的聊天机器人和助手的终极平台。 | [Botpress](https://github.com/botpress/botpress) | | AgentGPT | @ReworkdAI | 30.6k | AgentGPT 允许配置和部署 Autonomous Agents，自定义 AI，实现任何目标。 | [AgentGPT](https://github.com/reworkd/AgentGPT) | ================================================ FILE: src/agent-github-copilot-chat.md ================================================ # 编码智能体：Copilot Chat 是如何工作的 ```markdown 1. Deciding which workspace information to collect 2. Determining workspace structure… 3. Asking the model to update the user question and provide queries… 4. Running all tools… 5. Collecting workspace information ``` ## RAG 过程 ![](images/github-workspace-agent.png) ## Workspace Agent 模型策略 ``` 2024-04-15 11:46:05.940 [info] [chat fetch] url https://api.githubcopilot.com/chat/completions 2024-04-15 11:46:05.940 [info] [chat fetch] modelMaxPromptTokens 3072 2024-04-15 11:46:05.940 [info] [chat fetch] modelMaxResponseTokens 4096 2024-04-15 11:46:05.940 [info] [chat fetch] chat model gpt-4 2024-04-15 11:46:07.735 [info] [chat fetch] request.response: [https://api.githubcopilot.com/chat/completions], took 1795 ms 2024-04-15 11:46:19.135 [info] [streamMessages] message 0 returned. finish reason: [stop] 2024-04-15 11:46:19.136 [info] [streamChoices] request done: requestId: [d81668fd-e22d-4cd0-b899-e4a054efb7d3] responseId: [d81668fd-e22d-4cd0-b899-e4a054efb7d3] model deployment ID: [] 2024-04-15 11:46:19.153 [info] [chat fetch] url https://api.githubcopilot.com/chat/completions 2024-04-15 11:46:19.153 [info] [chat fetch] modelMaxPromptTokens 7168 2024-04-15 11:46:19.153 [info] [chat fetch] modelMaxResponseTokens 4096 2024-04-15 11:46:19.153 [info] [chat fetch] chat model gpt-3.5-turbo 2024-04-15 11:46:19.785 [info] [chat fetch] request.response: [https://api.githubcopilot.com/chat/completions], took 631 ms 2024-04-15 11:46:19.785 [info] [streamMessages] message 0 returned. finish reason: [stop] 2024-04-15 11:46:19.786 [info] [streamChoices] request done: requestId: [f7263ca2-0fa3-47d6-bb15-4929896db8fa] responseId: [f7263ca2-0fa3-47d6-bb15-4929896db8fa] model deployment ID: [x4dff5e5d11fc] ``` ### 理解阶段：GPT 4 生成本地查询机制数据 ```Javascript { rephrasedQuestion: "Where's the code for base64 encoding?", keywords: [ { keyword: "base64 encoding", variations: ["base64 encoder", "base64 encode"] }, { keyword: "base64", variations: ["base 64"] }, { keyword: "encode", variations: ["encoded", "encoder", "encoders"] } ] } ``` ### 总结阶段：GPT 3.5 Turbo 根据返回生成 生成数据示例： ## IDE 信息准备 ``` { header: 'Relevant function implementations', findImpls: relevantFunction }, { header: 'Relevant class declarations', findImpls: relevantClass }, { header: 'Relevant type declarations', findImpls: relevantType } ``` ```schema [ (constructor_declaration name: (identifier) @identifier body: (constructor_body) @body) (method_declaration name: (_) @identifier body: (block) @body) (lambda_expression body: (block) @body) ] @function ``` ================================================ FILE: src/agent-in-local-design.md ================================================ # 编码智能体：本地 AI 智能体 ### JetBrains #### Function Calling The function presented serves as a comprehensive search utility within JetBrains IDEs, It behaves like exact_search. The only difference is that this function allows not exact queries, as search is embedding-based in this case Use this function, IF YOU DO NOT KNOW THE **EXACT** NAME the named entity you are looking for OR if exact_search failed.", ```json { "type": "object", "properties": { "searchType": { "type": "string", "enum": ["actions", "symbols", "classes", "files"] }, "query": { "type": "string", "description": "Query in textual form for searching by entity names." } }, "required": ["searchType", "query"] } ``` exact_search: ```markdown This function serves as a robust search tool in JetBrains IDEs, allowing you to find IDE actions (like \"save file\", \"open file\"), symbols (functions, classes, methods), specific classes, and files containing project info like README.md. The search is based on the exact names of these entities, not their content, so craft your search queries accordingly. Use this function if the exact name of what you're searching for is available, and fallback to semantic_search if unsure or unsuccessful. In general PREFER this function over semantic_search, as the second one is more expensive. (for example if user specifies the exact class name like \"what does class do\") It provides a list of search results and their IDs and could return content for short results. Avoid mentioning IDs in the response. ``` ### 示例：AutoDev for VSCode ### 示例：Amazon Q [迁移 Agent](https://aws.amazon.com/cn/q/developer/code-transformation/) - [Upgrading language versions with the Amazon Q Developer Agent for code transformation](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/code-transformation.html) - [Modernize your Java application with Amazon Q Developer](https://aws.amazon.com/cn/blogs/devops/modernize-your-java-application-with-amazon-q-developer/) ### [自定义代码库](https://aws.amazon.com/cn/blogs/aws/customize-amazon-q-developer-in-your-ide-with-your-private-code-base/) [Customizing coding companions for organizations](https://aws.amazon.com/cn/blogs/machine-learning/customizing-coding-companions-for-organizations/) Indexing ![](images/aws-rag-indexing.png) Algorithms ![](images/aws-bm-25.png) 语义检索 [[Contriever](https://arxiv.org/pdf/2112.09118.pdf), [UniXcoder](https://arxiv.org/pdf/2203.03850.pdf)] _–_ 将查询和索引的代码片段转换为高维向量，并基于语义相似性对代码片段进行排序。正式来说，通常使用[k近邻 (KNN) 或近似最近邻 (ANN)](https://arxiv.org/abs/2101.12631) 搜索来找到其他具有相似语义的片段。 Semantic retrieval 过程 ![Amazon Q](images/cw_rag_semantic.png) 其它相关： - [MinJoin: Efficient Edit Similarity Joins via Local Hash Minima](https://arxiv.org/abs/1810.08833) - [CodeBLEU: a Method for Automatic Evaluation of Code Synthesis](https://arxiv.org/abs/2009.10297) ================================================ FILE: src/agent-infrastructure.md ================================================ # 编码智能体：编码智能体基础设施 ## Embedding 介绍 [AI Concepts](https://neon.tech/docs/ai/ai-concepts) ### AI概念 了解如何使用向量技术构建AI应用 向量技术是构建AI应用的核心组成部分。本文将介绍向量及其生成、使用和在Postgres中的存储方式。 #### 什么是向量？ 在处理非结构化数据时，一个常见的目标是将其转化为更易于分析和检索的结构化格式。这种转化可以通过“向量”实现，向量是包含一组浮点数的向量，代表数据的特征或维度。例如，像“牛跳过月亮”这样的句子可以表示为一个类似这样的向量：[0.5, 0.3, 0.1]。 向量的优点在于它们可以衡量不同文本片段之间的相似度。通过计算两个向量之间的距离，我们可以评估它们的相关性——距离越小，相似度越大，反之亦然。这一特性特别有用，因为它使向量能够捕捉文本的内在含义。 例如，考虑以下三句话： 1. 句子1：“牛跳过月亮。” 2. 句子2：“牛跳跃在天体之上。” 3. 句子3：“我喜欢吃煎饼。” 你可以按照以下步骤确定最相似的句子： 1. 为每个句子生成向量。假设这些值代表实际向量： - 句子1的向量 → [0.5, 0.3, 0.1] - 句子2的向量 → [0.6, 0.29, 0.12] - 句子3的向量 → [0.1, -0.2, 0.4] 2. 计算所有向量对（1&2, 2&3, 1&3）之间的距离。 3. 确定距离最短的向量对。 当我们应用这一过程时，句子1和句子2这两句都涉及跳跃的牛，根据距离计算，它们可能会被识别为最相关的。 #### 向量相似性搜索 将数据转化为向量并计算一个或多个项目之间的相似性被称为向量搜索或相似性搜索。这个过程有广泛的应用，包括： - 信息检索：通过将用户查询表示为向量，我们可以基于查询背后的意义执行更准确的搜索，从而检索到更相关的信息。 - 自然语言处理：向量捕捉文本的本质，使其成为文本分类和情感分析等任务的优秀工具。 - 推荐系统：利用向量相似性，我们可以推荐与给定项目相似的项目，无论是电影、产品、书籍等。这个技术允许我们创建更个性化和相关的推荐。 - 异常检测：通过确定数据集中项目之间的相似性，我们可以识别出不符合模式的异常项。这在许多领域中都至关重要，从网络安全到质量控制。 #### 距离度量 向量相似性搜索通过计算数据点之间的距离来衡量它们的相似性。计算数据点之间的距离有助于我们理解它们之间的关系。距离可以通过不同的度量方式计算。一些常见的距离度量包括： - 欧几里得距离（L2）：通常被称为“普通”距离，用尺子测量的距离。 - 曼哈顿距离（L1）：也称为“出租车”或“城市街区”距离。 - 余弦距离：计算两个向量之间角度的余弦。 pgvector扩展还支持其他距离度量，如汉明距离和雅卡尔距离。 不同的距离度量适用于不同的任务，具体取决于数据的性质和你关注的特定关系。例如，余弦相似性常用于文本分析。 #### 生成向量 生成向量的一种常见方法是使用LLM API，例如OpenAI的向量API。该API允许你将文本字符串输入到API端点，然后返回相应的向量。“牛跳过月亮”是一个具有3个维度的简单示例。大多数向量模型生成的向量具有更多的维度。OpenAI最新且性能最好的向量模型text-embedding-3-small和text-embedding-3-large默认生成1536和3072维度的向量。 以下是如何使用OpenAI的text-embedding-3-small模型生成向量的示例： ```bash curl https://api.openai.com/v1/embeddings \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $OPENAI_API_KEY" \ -d '{ "input": "Your text string goes here", "model": "text-embedding-3-small" }' ``` 注意：运行上述命令需要一个OpenAI API密钥，必须从OpenAI获取。 成功执行后，你将收到类似以下的响应： ```json { "object": "list", "data": [ { "object": "embedding", "index": 0, "embedding": [ -0.006929283495992422, -0.005336422007530928, ... (为了简洁省略) -4.547132266452536e-05, -0.024047505110502243 ], } ], "model": "text-embedding-3-small", "usage": { "prompt_tokens": 5, "total_tokens": 5 } } ``` 要了解更多关于OpenAI向量的信息，请参见[向量](https://beta.openai.com/docs/guides/embeddings)。 这里，你会找到一个从Amazon美食评论数据集（CSV文件）获取向量的示例。参见[获取向量](https://beta.openai.com/docs/guides/embeddings/obtaining-embeddings)。 你可以使用许多向量模型，例如由Mistral AI、Cohere、Hugging Face等提供的模型。AI工具如LangChain提供了处理各种模型的接口和集成。参见[LangChain: 文本向量模型](https://beta.openai.com/docs/guides/embeddings/langchain)。你还会在LangChain网站上找到Neon Postgres指南和Class NeonPostgres，它提供了与Neon Postgres数据库交互的接口。 #### 在Postgres中存储向量向量 Neon支持pgvector Postgres扩展，这使得可以直接在Postgres数据库中存储和检索向量向量。在构建AI应用时，安装该扩展消除了需要扩展架构以包含单独向量存储的需求。 从Neon SQL编辑器或任何连接到你的Neon Postgres数据库的SQL客户端运行以下CREATE EXTENSION语句即可安装pgvector扩展： ```sql CREATE EXTENSION vector; ``` 安装 pgvector 扩展后，你可以创建一个表来存储你的向量。例如，你可以定义一个类似如下的表来存储你的向量： ```sql CREATE TABLE items(id BIGSERIAL PRIMARY KEY, embedding VECTOR(1536)); ``` 要将向量添加到表中，你可以插入如下数据： ```sql INSERT INTO items(embedding) VALUES ('[ -0.006929283495992422, -0.005336422007530928, ... -4.547132266452536e-05, -0.024047505110502243 ]'); ``` 有关使用pgvector的详细信息，请参阅我们的指南：[pgvector扩展](https://beta.openai.com/docs/guides/embeddings/pgvector-extension)。 ## 查询算法 ### TF-IDF TF-IDF 是一种用于评估文档中关键词重要性的方法，它通过计算关键词在文档中的频率和在整个文档集合中的逆文档频率来评估关键词的重要性。 #### 变体：c-TF-IDF https://maartengr.github.io/BERTopic/getting_started/ctfidf/ctfidf.html c-TF-IDF 和传统的 TF-IDF 之间的关键区别在于它们的应用和分析层次： ### 传统的 TF-IDF - **文档级分析**：TF-IDF 代表词频-逆文档频率。它是一种统计度量，用于评估单词在文档中的重要性相对于整个文档集（语料库）。 - **计算**： - **词频（TF）**：测量一个术语 \( t \) 在文档 \( d \) 中出现的频率。 - **逆文档频率（IDF）**：测量一个术语在所有文档中的重要性。计算公式是 \( \log \left( \frac{N}{n_t} \right) \)，其中 \( N \) 是文档总数，\( n_t \) 是包含术语 \( t \) 的文档数。 - **TF-IDF 得分**：TF 和 IDF 的乘积。这个得分随着单词在文档中出现次数的增加而增加，但会被该单词在语料库中频率的增长所抵消。 ### c-TF-IDF - **簇/主题级分析**：c-TF-IDF 将 TF-IDF 调整为在簇或类别层面上工作，而不是单个文档层面。这种方法在主题建模中特别有用，例如在 BERTopic 中。 - **计算**： - **基于类别的词频（c-TF）**：每个簇（或类别）被视为单个文档。词频是基于这个合并文档中单词的频率计算的，并且针对主题大小的差异进行标准化。 - **基于类别的逆文档频率（c-IDF）**：调整以考虑每个类别的平均单词数。计算公式是 \( \log \left( 1 + \frac{A}{f_x} \right) \)，其中 \( A \) 是每个类别的平均单词数，\( f_x \) 是单词 \( x \) 在所有类别中的频率。 - **c-TF-IDF 得分**：c-TF 和 c-IDF 的乘积，给出一个单词在特定簇中的重要性相对于其他簇的得分。 ### c-TF-IDF 的优势 - **更好的主题表示**：通过关注文档的簇，c-TF-IDF 强调了一个簇中的文档与其他簇的文档之间的区别。 - **定制和模块化**：BERTopic 中的 c-TF-IDF 模型可以进行调优和定制，例如，应用不同的加权方案或减少频繁出现的词。 - **增强的鲁棒性**：像 bm25_weighting 和 reduce_frequent_words 这样的选项提供了对通常不会被过滤掉的常见词的额外鲁棒性。 ### BM25 算法 BM25 是一种基于概率的信息检索算法，用于评估文档与查询之间的相关性。BM25 算法的核心思想是通过计算文档中的关键词与查询中的关键词之间的匹配程度，来评估文档与查询之间的相关性。 ![BM25](images/bm25.png) [Elasticsearch 默认](https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-similarity.html) TF/IDF 基于相似性，具有内置的 tf 归一化，适用于短字段（如姓名）。详见 [Okapi_BM25](https://en.wikipedia.org/wiki/Okapi_BM25)。 此相似性具有以下选项： | 选项 | 描述 | |---------------------|--------------------------------------------------------------| | `k1` | 控制非线性词频归一化（饱和）。默认值为 `1.2`。 | | `b` | 控制文档长度在多大程度上归一化 tf 值。默认值为 `0.75`。 | | `discount_overlaps` | 确定在计算规范时是否忽略重叠标记（位置增量为 0 的标记）。默认情况下，此值为 true，即在计算规范时不计算重叠标记。 | 类型名称：`BM25` #### BM25f [介绍 Elasticsearch Relevance Engine™ — 为 AI 变革提供高级搜索能力](https://www.elastic.co/cn/blog/may-2023-launch-announcement) ### Jaccard 相似度 Jaccard 相似度是一种用于计算两个集合之间相似度的方法，它是通过计算两个集合的交集与并集之间的比例来评估它们之间的相似度。 ![Jaccard Similarity](images/calculate-jaccard-similarity.png) Jaccard 相似度的计算公式如下： ``` J(A, B) = |A ∩ B| / |A ∪ B| ``` Kotlin 实现： ```kotlin fun similarityScore(set1: Set, set2: Set): Double { val intersectionSize = set1.intersect(set2).size val unionSize = set1.union(set2).size return intersectionSize.toDouble() / unionSize } ``` TypeScript 实现： ```typescript function similarityScore(set1: Set, set2: Set): number { const intersectionSize: number = [...set1].filter(x => set2.has(x)).length; const unionSize: number = new Set([...set1, ...set2]).size; return intersectionSize / unionSize; } ``` ### SPLADE SPLADE（Sequential Pattern Mining by Limited Area DEcomposition）是一种用于发现序列模式的算法，它通过将序列划分为多个子序列，并在每个子序列上应用频繁模式挖掘算法来发现序列模式。 GitHub: https://github.com/naver/splade ### BM42 - [BM42: New Baseline for Hybrid Search](https://qdrant.tech/articles/bm42/) - 源码：[BM42](https://github.com/qdrant/bm42_eval) ```python sentences = "Hello, World - is the starting point in most programming languages" features = transformer.tokenize(sentences) # ... attentions = transformer.auto_model(**features, output_attentions=True).attentions weights = torch.mean(attentions[-1][0,:,0], axis=0) # ▲ ▲ ▲ ▲ # │ │ │ └─── [CLS] token is the first one # │ │ └─────── First item of the batch # │ └────────── Last transformer layer # └────────────────────────── Averate all 6 attention heads for weight, token in zip(weights, tokens): print(f"{token}: {weight}") # [CLS] : 0.434 // Filter out the [CLS] token # hello : 0.039 # , : 0.039 # world : 0.107 // <-- The most important token # - : 0.033 # is : 0.024 # the : 0.031 # starting : 0.054 # point : 0.028 # in : 0.018 # most : 0.016 # programming : 0.060 // <-- The third most important token # languages : 0.062 // <-- The second most important token # [SEP] : 0.047 // Filter out the [SEP] token ``` The resulting formula for the BM42 score would look like this: score ( D , Q ) = ∑ i = 1 N IDF ( q i ) × Attention ( CLS , q i ) ## 向量数据存储 ### 示例：JetBrains + Local Storage JetBrains 在进行 IDE 搜索时支持 DiskSynchronizedEmbedding 的方式，从远程服务器下载向量向量数据，然后将其存储在本地文件系统中。 降低了对远程服务器的依赖，提高了性能和稳定性。 优势： - 高效的读写操作。使用`RandomAccessFile`进行随机访问，提供高效的读写能力，避免了将整个文件加载到内存中，提高了性能。 - 增量更新。仅更新需要更改的部分，而不是重写整个存储文件，从而提高了写入效率，减少了资源消耗。 - 内存使用优化。通过按需加载和写入数据，显著减少内存占用，非常适用于大规模向量向量存储场景。 - 磁盘持久化。通过 LocalEmbeddingIndexFileManager 实现磁盘持久化存储，确保数据的持久性和可靠性。支持从磁盘加载和保存索引，增强数据恢复能力。 - 便于管理和维护。将ID和向量向量分开存储，分别为JSON文件和二进制文件，便于管理和维护。 缺点： - 本地存储限制。依赖本地存储空间，可能会受到硬件限制，如果向量向量数据量非常大，可能需要频繁监控和管理存储资源。 - 性能瓶颈。在高并发环境下，读写锁的争用可能成为性能瓶颈。极端情况下，可能会出现性能下降的问题，需要进一步优化和调整。 - 不支持分布式访问。由于数据存储在本地文件系统中，不支持跨服务器或分布式系统访问，限制了应用场景。 ### 示例：Sweep + Redis [Our simple vector database implementation](https://docs.sweep.dev/blogs/vector-db-implementation) 优势： - 管理多个索引的复杂性： - 标准的向量数据库在处理单个索引时表现良好，但在管理多个索引、频繁更新和自托管时变得复杂。 - 使用 Redis 可以简化这一过程，无需管理多个索引和重建索引的问题。 - 基础设施和依赖管理： - 使用外部存储（如 Pinecone）会引入额外的依赖和潜在的故障点。 - Redis 是一个流行的开源内存数据库，可以轻松自托管，减少了对外部服务的依赖。 - 缓存机制： - Redis 非常适合缓存用途，可以快速读取和写入数据，这对于频繁访问的 Embedding 向量非常重要。 - 通过使用 Redis，系统可以缓存 Embedding 结果，减少对 OpenAI API 的调用次数，降低成本和延迟。 缺点： - 该方法速度较慢（每个查询大约1秒），但满足他们的需求。 - 系统在超过 100 万个向量向量时扩展性不佳，但符合他们当前的需求（通常每个代码库文件少于30k）。 ### 示例：通义灵码 + RocksDB RocksDB 是一个开源的向量式键值存储引擎，由 Facebook 开发并开源。它在许多方面有着显著的优势： 1. **高性能**：RocksDB 被优化用于快速的随机读/写操作，适合需要高吞吐量和低延迟的应用场景。它支持并发操作，能够有效地处理大量的并发读写请求。 2. **可调优性**：RocksDB 提供了多种调优选项，允许用户根据具体的应用需求进行配置。例如，可以调整内存使用、写入策略、压缩算法等，以最大化性能和资源利用率。 3. **持久性**：RocksDB 具备持久化特性，即数据写入后可靠保存。这使得它非常适合作为后端存储引擎，支持需要持久化存储的应用程序。 4. **可扩展性**：RocksDB 的设计支持数据的水平扩展。它可以在多个节点上部署，通过分区和复制来实现数据的高可用性和可扩展性。 5. **内存效率**：RocksDB 能够有效地管理内存，尤其是对于大型数据集。它通过有效的缓存策略和紧凑的数据结构，降低了内存占用并提高了整体的效率。 6. **灵活性**：RocksDB 支持多种数据模型，包括键值对、列族存储等。这种灵活性使得它可以应用于各种不同类型的存储需求，从简单的键值存储到更复杂的列存储系统。 总体来说，RocksDB 在性能、可靠性和灵活性方面都表现出色，使其成为许多大型互联网公司和应用程序的首选存储引擎之一。 ```bash /Users/phodal/.lingma/tmp/cache/v3.3 ├── 000001.vlog ├── 00001.mem ├── DISCARD ├── KEYREGISTRY ├── LOCK └── MANIFEST ``` RocksDB 体积： ```bash -rw-r--r-- 1 phodal staff 13M 13 Jul 11:04 librocksdbjni-linux-aarch64-musl.so -rw-r--r-- 1 phodal staff 13M 13 Jul 11:02 librocksdbjni-linux-aarch64.so -rw-r--r-- 1 phodal staff 16M 13 Jul 11:00 librocksdbjni-linux-ppc64le-musl.so -rw-r--r-- 1 phodal staff 17M 13 Jul 11:00 librocksdbjni-linux-ppc64le.so -rw-r--r-- 1 phodal staff 13M 13 Jul 11:09 librocksdbjni-linux-riscv64.so -rw-r--r-- 1 phodal staff 15M 13 Jul 11:05 librocksdbjni-linux-s390x-musl.so -rw-r--r-- 1 phodal staff 15M 13 Jul 11:05 librocksdbjni-linux-s390x.so -rw-r--r-- 1 phodal staff 14M 13 Jul 05:39 librocksdbjni-linux32-musl.so -rw-r--r-- 1 phodal staff 14M 13 Jul 04:49 librocksdbjni-linux32.so -rw-r--r-- 1 phodal staff 14M 13 Jul 06:06 librocksdbjni-linux64-musl.so -rw-r--r-- 1 phodal staff 14M 13 Jul 05:11 librocksdbjni-linux64.so -rw-r--r-- 1 phodal staff 8.5M 13 Jul 04:28 librocksdbjni-osx-arm64.jnilib -rw-r--r-- 1 phodal staff 9.9M 13 Jul 04:12 librocksdbjni-osx-x86_64.jnilib -rw-r--r-- 1 phodal staff 8.0M 13 Jul 11:10 librocksdbjni-win64.dll ``` ### 示例：Tabnine + [Qdrant](https://docs.tabnine.com/main/welcome/readme/personalization/tabnines-personalization-in-depth) RAG 是一种常见的人工智能框架，通过添加信息检索组件来提高LLM生成答案的准确性，该组件为模型的每个查询添加数据和上下文。 RAG 的实现包括两个组成部分： - 索引建立：Tabnine 构建了 RAG 索引，以便快速有效地检索相关数据。这些索引用于代码完成和聊天，可以基于本地代码或全局代码，依赖于 IDE 工作空间或组织的全局代码库中的所有代码。 - 查询：对于 Tabnine 收到的每个用户查询（无论是显式还是隐式的），Tabnine 会从 RAG 索引中检索相关的代码上下文，并将其作为上下文添加到AI模型的提示中。结果是 Tabnine 提供了更准确的代码建议，更符合用户代码库的需求。 当涉及到 RAG 索引的内容时，可以按照以下目录进行总结： 1. **索引类型**：代码补全索引和聊天索引 2. **索引范围**：本地索引：基于每个开发者的IDE工作空间、全局索引：基于整个组织的代码库 3. **被索引的文件类型**：符合特定文件扩展名的文件、未列在 .ignore 或 .gitignore 中的文件、不包括特定扩展名的文件："md", " yaml", "yml", "json", "lock", "xml", "gradle", "bash", "sh", "txt", "csv" 4. **索引生命周期**：本地代码补全和聊天上下文索引的创建和增量更新、连接到组织代码库的索引的定期更新 5. **索引过程**：向量向量应用于每个代码块、代码补全索引计算在开发者的本地机器上运行、聊天索引计算需要 GPU，在 Tabnine 服务器上执行 6. **索引位置和持久化**：持久化在最终用户本地机器上的向量数据库（qdrant） 7. **与组织代码库连接的集成**：与 GitHub、GitLab 或 Bitbucket 等主要 Git 托管平台的集成、保持现有权限模型，只允许用户访问其有权限的存储库 这些总结点可以帮助理解 RAG 索引的不同方面和实现方式。 ### 示例：Neon serverless Postgres + pgvector [pgvector: 30x Faster Index Build for your Vector Embeddings](https://neon.tech/blog/pgvector-30x-faster-index-build-for-your-vector-embeddings) **pgvector**是Postgres中最受欢迎的向量相似性搜索扩展。向量搜索在语义搜索和检索增强生成（RAG）应用中变得越来越重要，增强了大型语言模型（LLMs）的长期记忆能力。 在语义搜索和RAG应用中，数据库包含LLM未训练过的知识库，被分成一系列文本或块。每个文本保存在一行，并与一个由向量模型（如OpenAI的ada-embedding-002或Mistral-AI的mistral-embed）生成的向量相关联。 向量搜索用于找到与查询向量最相似的文本。这通过将查询向量与数据库中的每一行进行比较来实现，这使得向量搜索难以扩展。因此，pgvector实现了近似最近邻（ANN）算法（或索引），通过对数据库的一个子集进行向量搜索以避免冗长的顺序扫描。 **Hierarchical Navigable Small World（HNSW）**索引是最有效的ANN算法之一。其基于图的多层结构设计用于数十亿行的向量搜索，使HNSW在大规模上极为快速和高效，因此成为向量存储市场中最受欢迎的索引之一。 #### HNSW的两个主要缺点 1. **内存**：HNSW索引比其他索引（如倒排文件索引IVFFlat）需要更多的内存。这个问题可以通过使用更大的数据库实例解决，但对于使用AWS RDS等独立Postgres的用户来说，可能会遇到因为索引构建而需要过度配置的问题。利用Neon的扩展能力，可以在构建HNSW索引时扩展，之后再缩减以节省成本。 2. **构建时间**：HNSW索引对于百万行数据集可能需要数小时的构建时间，这主要是由于计算向量间距离所花费的时间。pgvector 0.6.0通过引入并行索引构建解决了这一问题，使得索引构建速度提高了30倍。 #### 并行索引构建的必要性 虽然HNSW索引支持更新，但在以下两种情况下需要重新创建HNSW索引： 1. 希望加快查询速度并优化向量搜索时。 2. 已有HNSW索引，但表中删除了向量时，可能会导致索引搜索返回假阳性，从而影响LLM响应质量和AI应用的整体性能。 ## 向量模型 Massive Text Embedding Benchmark (MTEB) Leaderboard. [排名](https://huggingface.co/spaces/mteb/leaderboard) ### FlagEmbedding [FlagEmbedding](https://github.com/FlagOpen/FlagEmbedding) ### [BAAI/bge-small-zh-v1.5](https://huggingface.co/BAAI/bge-small-zh-v1.5) ### 相关库 - [FastEmbed](https://github.com/qdrant/fastembed) is a lightweight, fast, Python library built for embedding generation. - [ONNX Runtime](https://onnxruntime.ai/) is a cross-platform inference and training machine-learning accelerator. [ONNX Runtime 语言支持](https://onnxruntime.ai/docs/get-started/) ## 相关资源 ### BERTopic - [BERTopic: How to Build a Topic Model with BERT](https://maartengr.github.io/BERTopic/algorithm/algorithm.html) ![Bert Topic Modularity](images/bert-topic-modularity.svg) 示例代码： ```Python from umap import UMAP from hdbscan import HDBSCAN from sentence_transformers import SentenceTransformer from sklearn.feature_extraction.text import CountVectorizer from bertopic import BERTopic from bertopic.representation import KeyBERTInspired from bertopic.vectorizers import ClassTfidfTransformer # Step 1 - Extract embeddings embedding_model = SentenceTransformer("all-MiniLM-L6-v2") # Step 2 - Reduce dimensionality umap_model = UMAP(n_neighbors=15, n_components=5, min_dist=0.0, metric='cosine') # Step 3 - Cluster reduced embeddings hdbscan_model = HDBSCAN(min_cluster_size=15, metric='euclidean', cluster_selection_method='eom', prediction_data=True) # Step 4 - Tokenize topics vectorizer_model = CountVectorizer(stop_words="english") # Step 5 - Create topic representation ctfidf_model = ClassTfidfTransformer() # Step 6 - (Optional) Fine-tune topic representations with # a `bertopic.representation` model representation_model = KeyBERTInspired() # All steps together topic_model = BERTopic( embedding_model=embedding_model, # Step 1 - Extract embeddings umap_model=umap_model, # Step 2 - Reduce dimensionality hdbscan_model=hdbscan_model, # Step 3 - Cluster reduced embeddings vectorizer_model=vectorizer_model, # Step 4 - Tokenize topics ctfidf_model=ctfidf_model, # Step 5 - Extract topic words representation_model=representation_model # Step 6 - (Optional) Fine-tune topic represenations ) ``` ================================================ FILE: src/agent-onboarding.md ================================================ # 编码智能体：新人上手项目 ## Onboarding Agent ### Onboarding Agent [Onboarding Agent](https://www.tabnine.com/blog/introducing-tabnines-onboarding-agent-revolutionizing-developer-onboarding/) Onboarding Agent 是 Tabnine Chat 中的一项新功能，专为开发人员在新项目中快速适应而设计。它通过提供关键项目信息和指导，极大地简化了开发人员的入职过程。 ![Onboarding Agent](images/onboarding.gif) 1. **集成与可用性**： - 作为 Tabnine Chat 的内置命令，无缝集成。 - 对所有 Tabnine SaaS 用户和支持 Tabnine AI 的 IDE 兼容。 2. **操作简便**： - 可通过简单命令 (/onboarding) 或在新对话开始时自动触发。 - 提供项目结构、可运行脚本、依赖关系等的简明总结。 3. **互动和个性化**： - 不仅提供信息摘要，还作为一个导游，为用户提供定制的后续问题建议。 - 让开发人员可以根据自己的需要深入探索项目的特定部分。 对开发人员的益处： - **提高效率**：加快了新项目的熟悉过程，节省时间。 - **增强自主性**：使开发人员能够独立地了解和操作项目。 - **快速上手**：帮助他们更快地成为项目团队的有效成员。 对组织的益处： - **降低成本**：减少了资深团队成员辅助新人的时间成本。 - **优化工作流程**：简化了新成员加入或项目切换带来的工作中断。 - **知识分享**：促进组织内部的效率和知识共享文化。 Onboarding Agent 代表了开发工具领域的重要进展，旨在提升开发效率，加速项目启动时间，为组织带来更高的创新能力和竞争力。 ================================================ FILE: src/agent-refactoring-test.md ================================================ # 编码智能体：测试智能体与 IDE 插件结合 ## 示例 ### AutoDev https://ide.unitmesh.cc/custom/extension-context-agent ```json { "name": "@autodev.ext-context.test", "description": "AutoTest", "url": "http://127.0.0.1:8765/api/agent/auto-test", "responseAction": "Direct" } ``` 对应的模板文件如下： ```Velocity Write unit test for following ${context.lang} code. ${context.frameworkContext} #if( $context.relatedClasses.length() > 0 ) Here is the relate code maybe you can use ${context.relatedClasses} #end #if( $context.currentClass.length() > 0 ) This is the class where the source code resides: ${context.currentClass} #end ${context.extContext} Here is the source code to be tested: ${context.imports} ${context.sourceCode} #if($context.isNewFile) Should include package and imports. Start method test code with Markdown code block here: #else Should include package and imports. Start ${context.testClassName} test code with Markdown code block here: #end ``` 对应的 Kotlin 代码： ```Kotlin private fun getCustomAgentTestContext(testPromptContext: TestCodeGenContext): String { if (!project.customAgentSetting.enableCustomRag) return "" val agent = loadTestRagConfig() ?: return "" val query = testPromptContext.sourceCode val stringFlow: Flow = CustomAgentExecutor(project).execute(query, agent) ?: return "" val responseBuilder = StringBuilder() runBlocking { stringFlow.collect { string -> responseBuilder.append(string) } } return responseBuilder.toString() } ``` ================================================ FILE: src/agent-remote.md ================================================ # 编码智能体：远程 AI 智能体 ## 示例 ### AutoDev 详细见：https://ide.unitmesh.cc/agent/custom-ai-agent.html ```json [ { "name": "内部 API 集成", "description": "在一个组织或项目中，不同系统或组件之间的通信接口。", "url": "http://127.0.0.1:8765/api/agent/api-market", "responseAction": "Direct" }, { "name": "组件库查询", "description": "从组件库中检索特定的 UI 组件，以便在开发的应用程序中使用。", "url": "http://127.0.0.1:8765/api/agent/component-list", "responseAction": "TextChunk" }, { "name": "页面生成", "description": "使用 React 框架，基于组件和状态来生成页面。", "url": "http://127.0.0.1:8765/api/agent/ux", "auth": { "type": "Bearer", "token": "eyJhbGci" }, "responseAction": "WebView" }, { "name": "DevInInsert", "description": "Update，並指定20秒的timeout時間", "url": "http://127.0.0.1:8765/api/agent/devins-sample", "responseAction": "DevIns", "defaultTimeout": 20 } ] ``` ### GitHub Copilot Extension ================================================ FILE: src/agent-understand-rag.md ================================================ # 编码智能体：理解 RAG 的应用 RAG 示例 ![](images/rag-define.png) ## RAG 过程 [Advanced RAG Techniques](https://weaviate.io/blog/advanced-rag) ### Indexing - textChunking 有效的索引对于任何 RAG 系统来说都至关重要。第一步涉及如何摄取、分块和存储数据。 #### 简单文本 Chunking - 概述：这种方法将文档按固定大小进行分块，并带有一些重叠。这确保每个块保留前一个块的上下文。 - 实现：可以指定一个块大小（例如 35 个字符）和一个重叠大小以在块之间保持上下文。此方法适用于简单文档，但可能不适用于更复杂的文本，也无法利用文档结构。 - 优缺点：实现简单，但可能会打断语义单元，导致块不连贯，从而降低检索性能。 ![](images/rag-text-chunking.png) 详细代码：[RetrievalTutorials](https://weaviate.io/blog/advanced-rag) #### 特定文档 Chunking #### 语义化 Chunking - 概述：语义分块是基于意义而不是固定大小来划分文本。这种技术确保每个块代表一个连贯的信息片段。 - 实现：计算句子嵌入之间的余弦距离。如果两个句子在语义上相似（低于某个阈值），它们属于同一个块。这种方法根据内容的语义结构创建可变长度的块。 - 优缺点：产生更连贯和语义上有意义的块，提高检索准确性，但需要通过基于 BERT 的编码器模型进行前向传播，这比简单分块更具计算密集型。 ![](images/rag-semantic-chunking.png) #### 基于图（抽象语法树）的 Chunking - 概述：这种方法使用抽象语法树（AST）来分块文本。AST 是代码的结构化表示，可以帮助识别代码块的边界。 - 实现：使用 AST 解析代码，识别代码块的开始和结束。这种方法适用于代码文本，因为代码通常具有结构化的语法。 - 优缺点：生成高质量的块，但需要专门的代码解析器，适用于代码文本，不适用于自然语言文本。 #### 基于 LLM 的 Chunking - 概述：这种高级方法使用语言模型从文本中创建自包含的命题，确保每个块在语义上是完整的。 - 实现：使用一个语言模型（例如一个拥有 70 亿参数的模型）处理文本，将其分解为独立有意义的命题。然后模型将这些命题组合成块，平衡语义完整性和上下文。这种方法计算密集，但提供最高的准确性。 - 优缺点：适应文本细微差别，生成高质量的块，但计算密集，并且可能需要针对特定应用进行微调。 示例：https://huggingface.co/chentong00/propositionizer-wiki-flan-t5-large #### 基于 Agentic 的 Chunking 示例：[AgenticChunker](https://github.com/FullStackRetrieval-com/RetrievalTutorials/blob/a4570f3c4883eb9b835b0ee18990e62298f518ef/tutorials/LevelsOfTextSplitting/agentic_chunker.py) ### Indexing -结合元数据 元数据提供了额外的上下文，可以显著提高检索的准确性。通过整合日期、患者年龄和既往病史等元数据，可以在搜索过程中过滤掉无关信息。过滤有助于缩小搜索范围，使检索过程更加高效和相关。 #### 添加和基于元数据的过滤 **概述**：元数据提供了额外的上下文，可以显著提高检索的准确性。通过整合日期、患者年龄和既往病史等元数据，可以在搜索过程中过滤掉无关信息。过滤有助于缩小搜索范围，使检索过程更加高效和相关。 **实现**：在索引数据时，将元数据与矢量化文本一起存储。例如，如果索引患者记录，包含元数据如年龄、就诊日期和特定病情。在搜索时使用这些元数据过滤搜索结果，确保系统只检索相关信息。 例如，如果查询与儿科患者有关，首先过滤掉18岁以上患者的记录，然后再执行语义搜索。这减少了检索结果中的噪音，增强了输出的相关性。 ![MetaData Fitler](images/indexing-metadata-filter.png) 参考：[MyScale](https://medium.com/@myscale/optimizing-filtered-vector-search-in-myscale-77675aaa849c) #### 使用GLiNER为分块生成元数据 有时你可能没有丰富的元数据来增强你的分块，但使用GLiNER（通用线性命名实体识别器）模型可以实时从分块中生成元数据！GLiNER是一个基于BERT的强大模型，可以在摄取阶段对分块进行标记和标签创建元数据，从而显著改善检索过程。 **自动标记与GLiNER**： **实现**：你可以将每个分块和你想要识别的标签一起提供给GLiNER。如果在分块文本中找到这些标签，它将识别它们；如果没有匹配到高置信度的内容，则不会生成标签，从而减少误报。 **优缺点**：对于一般用途效果很好，但可能需要针对特定领域的数据集和应用进行微调。 **查询解析和过滤**： **实现**：GLiNER的另一个用途是解析传入的查询，并将其与标记的元数据匹配以过滤结果。 **优缺点**：通过确保上下文相关性提高了检索准确性，但增加了一个额外的处理步骤。 参考：GLiNER: 通用命名实体识别模型使用双向变压器。示例：[GLiNER Demo](https://huggingface.co/spaces/urchade/gliner_multiv2.1) 这些技术为建立一个强大的RAG系统奠定了基础，使得从大数据集中进行高效检索成为可能。选择哪种分块方法和如何使用元数据将取决于你的数据集的具体需求和特性。 ### Retrieval：提高矢量数据库检索召回率 为了增强RAG（Retrieval-Augmented Generation）系统中的检索部分，可以采用以下几种技术来显著提高与查询相关的文档召回率，从而提高LLM（大语言模型）生成高质量结果的几率： #### 1. 混合搜索 混合搜索结合了矢量搜索和关键词搜索的优势，以提高检索的准确性。 - **矢量搜索**：捕捉查询的语义含义。 - **关键词搜索**：识别特定术语的精确匹配。 在医学等领域，许多术语和概念并不是通过语义理解的，而是特定的关键词，如药物名称、解剖术语、疾病名称和诊断。纯粹的矢量搜索可能会遗漏这些关键字，而基于关键词的搜索确保了特定重要术语被考虑在内。通过整合这两种方法，混合搜索允许更全面的检索过程。 这两种搜索方法（矢量和关键词搜索）并行运行，然后根据加权系统合并和排序结果。例如，使用Weaviate，可以调整alpha参数以平衡矢量与关键词搜索结果的重要性，创建一个综合的、排序的文档列表。这种方法平衡了精度和召回率，改善了整体检索质量，但需要仔细调整加权参数。 #### 2. 查询重写 查询重写考虑到人类查询可能并不适合矢量数据库或语言模型。通过利用语言模型重写查询，可以显著改善检索过程。 - **矢量数据库的查询重写**：将患者的初始查询转换为更适合数据库的格式。例如，将“我的左肩疼痛，拇指和食指麻木”重写为“左肩疼痛。麻木。食指麻木”。 - **语言模型的提示重写**：自动和互动式地构建提示以优化与语言模型的交互，提升生成结果的质量和准确性。框架如DSPy可以帮助实现这一过程。 这些重写的查询和提示确保检索过程更好地理解和检索相关文档，并优化语言模型的提示。可以通过以下方式实现查询重写： **示例**： - 初始查询：My left shoulder hurts and I have numbness in my thumb and index finger. - 重写查询：Pain left shoulder. Numbness. Numbness index finger. 这不仅使搜索过程更能理解和检索相关文档，而且使语言模型获得最佳提示，从而生成更高质量的结果。 ![Query Rewrite](images/rag-query-rewrite.png) #### 3. 微调 [Fine-Tuning Cohere's Reranker](https://weaviate.io/blog/fine-tuning-coheres-reranker) ### Generation 最后，我们讨论如何提高和控制语言模型 (LLM) 的生成质量。关键在于确保提供给 LLM 的上下文尽可能与提示相关，否则不相关的数据可能会引发幻觉。以下是一些实现更好生成结果的技巧： #### 1. 自动剪切以移除无关信息 自动剪切是一种过滤从数据库中检索到的无关信息的方法，否则这些信息可能会误导 LLM 并导致幻觉。其工作原理如下： - **检索并评分相似性**：当查询被提出时，会检索到多个对象及其相似性分数。 - **识别并剪切**：使用相似性分数，识别分数显著下降的截断点。超过此点的对象被认为是相关性较低的，自动排除在外。 例如，如果检索到六个对象，相似性分数可能在第四个对象后急剧下降。通过检查相似性分数的变化率，可以确定哪些对象应被排除，从而确保仅将最相关的信息提供给 LLM。 参考：AutoCut #### 2. 对检索到的对象重新排序 重新排序涉及使用一个更复杂的模型重新评估和重新排序初步检索到的对象，以根据其与查询的相关性增强最终检索集的质量。其工作原理如下： - **过度获取**：初步检索到比所需数量更多的对象。 - **应用排序模型**：使用高延迟的复杂模型（通常是交叉编码器），对每个检索到的对象的相关性进行重新评估。该模型成对地考虑查询和每个检索到的对象以重新评估其相似性。 - **重新排序结果**：根据新的评估结果重新排序对象，以反映最相关的结果排在最前面。 这种方法确保最相关的文档优先，提高提供给 LLM 的数据的整体质量。 参考：AutoCut #### 3. 结合机器学习 PostGresML: [How-to Improve Search Results with Machine Learning](https://postgresml.org/blog/how-to-improve-search-results-with-machine-learning) 以下是主要内容的总结： 1. **PostgresML的优势**： - PostgresML让在数据库中使用机器学习变得容易，并能够在云中水平扩展工作负载。 - 通过组合不同的NLP和机器学习模型，改进搜索引擎的搜索结果。 2. **关键字搜索**： - 搜索引擎通常由多层组成，从简单到复杂，逐步改进结果。 - 传统的关键字搜索是基础，通过词干提取（stemming）和标准SQL函数（如`to_tsvector`和`to_tsquery`）来实现。 3. **索引和性能优化**： - 通过生成列（generated columns）和广义倒排索引（GIN），可以显著提高搜索性能。 - 这减少了对全表扫描的需求，使搜索更加高效。 4. **结果排序（Ranking）**： - 排序是搜索的关键，Postgres提供了`ts_rank`函数，通过计算关键词匹配的词频（TF）来确定相关性分数。 - 可以通过简单的加权公式来提升标题和正文匹配的相关性。 5. **机器学习排序（Learning to Rank）**： - 机器学习通过用户点击数据来训练模型，从而更智能地排序搜索结果。 - 收集用户点击数据并将其转化为特征用于训练模型，可以显著提高排序的准确性。 6. **模型训练和预测**： - 使用`pgml.train`函数来训练模型，预测用户点击的概率。 - 通过`pgml.predict`函数在新数据上应用训练好的模型来重新排序搜索结果。 7. **组合查询**： - 使用公用表表达式（CTEs）和SQL的强大功能，可以分步骤高效地处理搜索和重新排序。 8. **下一步改进**： - 添加更多特征，如文档的受欢迎度或质量指标，进一步优化预测模型。 - 使用更复杂的机器学习算法，如XGBoost、LightGBM等，来提高排序效果。 主要步骤： - **创建数据表**：使用标准SQL语句创建文档表，并插入样例数据。 - **实现基础搜索**：通过关键字搜索和词干提取，查找包含指定词语的文档。 - **优化性能**：生成和索引词向量，提升搜索效率。 - **排序结果**：使用`ts_rank`函数根据关键词匹配程度进行排序。 - **提升相关性**：通过用户点击数据训练机器学习模型，优化排序。 - **应用模型**：使用训练好的模型重新排序搜索结果。 通过以上方法，可以显著提高搜索结果的相关性和用户体验。 #### 4. 微调 LLM 在领域特定数据上微调 LLM 可以显著增强其在该领域的表现。例如，使用类似 Meditron 70B 的模型，这是在医学数据上专门微调的 LLaMA 2 70b 版本，通过以下方式实现： - **无监督微调**：在大量领域特定文本（如 PubMed 文献）上继续预训练模型。 - **有监督微调**：使用有监督学习在领域特定任务（如医学多项选择题）上进一步微调模型。 这种专业化的训练有助于模型在目标领域表现优异，在特定任务中超越其基础模型和更大但不专业的模型（如 GPT-3.5）。 这些技术结合在一起，确保了 LLM 生成过程中的高质量和高相关性，从而显著提升最终生成结果的可靠性和准确性。 ## RAG 应用开发过程 Shire RAG 示例 ```shire --- name: "Search" variables: "testTemplate": /.*.java/ { caching("disk") | splitting | embedding | searching("comment") } --- 根据如下的代码，回答用户的问题：博客创建的流程 $testTemplate ``` ### 代码切割 Code Splitter 模块是一个代码分割模块，用于将代码分割成多个片段，以便进行各种代码相关任务，如代码相似度计算、代码分类、代码聚类等。 ### 拆分策略 根据《[Chunking 2M+ files a day for Code Search using Syntax Trees](https://docs.sweep.dev/blogs/chunking-2m-files)》 的建议： 1. 代码的平均 Token 到字符比例约为1:5（300 个 Token），而嵌入模型的 Token 上限为 512 个。 2. 1500 个字符大约对应于 40 行，大致相当于一个小到中等大小的函数或类。 3. 挑战在于尽可能接近 1500 个字符，同时确保分块在语义上相似且相关上下文连接在一起。 #### TreeSitter 语法树 结合后续更新：《[Improving LlamaIndex’s Code Chunker by Cleaning Tree-Sitter CSTs](https://docs.sweep.dev/blogs/chunking-improvements)》 1. **Span 数据结构**：引入用于高效表示字符串片段的 Span 数据结构，有助于管理和连接代码块。 2. **处理语法树中的间隙**：通过调整语法树节点的结束字节，使其与下一个节点的开始字节匹配，从而解决语法树中节点之间的间隙问题，提高了代码块的准确性。 3. **改进的代码块化算法**：使用 Span 改进了代码块化算法，使代码更清晰，更好地处理代码块的大小，确保代码块大小合适并能正确连接。 4. **转向基于行的代码块**：从字节索引转向行号，处理编码问题并消除空代码块，提升了代码块化结果的兼容性和可读性。 5. **应对速率限制**：通过分批处理文件和有选择性地重新索引活跃用户和付费用户的方法，有效管理 Modal 平台的速率限制，优化了代码库更新时的资源使用。 #### 常规的代码分词 - TF-IDF - 基于 AST - 基于行数 多种不同方式： - 基于关键字分割：LangChain - 经典语法分析 - Antlr - 基于规则 DSL的语法分析：LlamaIndex - TreeSitter: [https://tree-sitter.github.io/tree-sitter/](https://tree-sitter.github.io/tree-sitter/) #### 中文文档分词 分词 - WordNet, [Chinese WordNet](https://github.com/lopentu/CwnGraph) - Jieba #### 混合方式 Chunk/Document 拆分策略 1. 如果代码类少于 1500 个字符，则将整个代码类作为一个代码块。 2. 如果代码类大于 1500 个字符，则将代码类分成多个函数代码块。 代码块逻辑 1. 代码块的第一部分是上下文相关的注释，诸如包名、类名等。 2. 代码块的第二部分是代码块的内容。 示例： ```chunk // canonicalName: com.google.common.collect.ImmutableList public static ImmutableList of(T... elements) { List list = new ArrayList<>(); Collections.addAll(list, elements); return new ImmutableList<>(list); } ``` ### 向量化（Embedding） 向量化模型 #### 模型选择 [Step-by-Step Guide to Choosing the Best Embedding Model for Your Application](https://weaviate.io/blog/how-to-choose-an-embedding-model) #### Sentence Transformers > Sentence Transformers 是一个自然语言处理工具，用于将文本句子嵌入到一个高维向量空间中，以便进行各种文本相关任务，如文本相似度计算、 > 文本分类、聚类等。它是通过预训练的深度学习模型实现的，通常使用诸如BERT、RoBERTa、DistilBERT等预训练模型作为其基础架构。 在这里，我们使用的 SentenceTransformers 模型是：[sentence-transformers/all-MiniLM-L6-v2](https://huggingface.co/sentence-transformers/all-MiniLM-L6-v2)， 在体积上只有 22M，因此被 Bloop、GitHub Copilot 作为本地向量化模型，也因此是 ChocoBuilder 的默认的本地矢量化模块。 - all-MiniLM-L6-v2 支持转为 384 维稠密向量空间（dimensional dense vector space），即 384 可以使用 [optimum](https://github.com/huggingface/optimum) 优化模型，将模型转换为 ONNX 格式，以便于在本地进行推理。 #### 模型训练 OnnxRuntime ## 相关资源 ### 距离算法 [Distance Metrics in Vector Search](https://weaviate.io/blog/distance-metrics-in-vector-search#cosine-similarity) ### 相似度 Netflix 相关研究：[Is Cosine-Similarity of Embeddings Really About Similarity?](https://arxiv.org/abs/2403.05440) > 余弦相似度是两个向量之间夹角的余弦值，等价于它们归一化后的点积。一个常见的应用是通过将余弦相似度应用于学习得到的低维特征嵌入，来量化高维对象之间的语义相似性。在实践中，这种方法有时比未归一化的嵌入向量之间的点积效果更好，但有时也可能更差。为了深入理解这一经验观察，我们研究了基于正则化线性模型导出的嵌入，闭式解法有助于进行分析。我们从理论上推导了余弦相似度如何可能产生任意的、因此无意义的" 相似性" 。对于某些线性模型而言，这些相似性甚至不是唯一的，而对于其他模型，则受正则化的隐式控制。我们讨论了超出线性模型的影响：在学习深度模型时结合了不同的正则化技术；当对结果嵌入进行余弦相似度计算时，这些技术具有隐含的、非预期的影响，使结果变得难以理解且可能是任意的。基于这些见解，我们警告不要盲目使用余弦相似度，并概述了一些替代方法。 ## 业内案例 - Codium: [RAG for a Codebase with 10k Repos](https://www.codium.ai/blog/rag-for-large-scale-code-repos/) - Sweep AI: [Chunking 2M+ files a day for Code Search using Syntax Trees](https://docs.sweep.dev/blogs/chunking-2m-files) ### 混合搜索 ![](images/how_hybrid_search_works.png) 结合：[A Review of Hybrid Search in Milvus](https://zilliz.com/blog/a-review-of-hybrid-search-in-milvus) 如下提 Milvus 的混合搜索过程： ![](images/what_is_the_hybrid_search_process_within_Milvus.png) 对应的 ReRanker 模块： ![](images/how_reranking_works.png) - 排序检索融合（RRF）。RRF是一种数据融合算法，它基于检索结果的倒数排名进行结果的合并。它平衡了每个向量字段的影响，尤其是在没有明确的重要性优先级时。 当你希望对所有向量字段给予同等考虑，或者每个字段相对重要性不确定时，会使用这种策略。 - 加权排名器（WeightedRanker）。加权排名器策略根据每个向量字段的重要性，为来自每个向量检索路径的结果分配不同的权重。 当每个向量字段的重要性不同时，应用这种重新排序策略，允许你通过分配更高的权重来强调某些向量字段。例如，在多模态搜索中，文本描述可能被认为比图像中的颜色分布更重要。 ### RAG 评估 [RAG Evaluation: Detecting Hallucinations with Patronus AI and MongoDB](https://www.mongodb.com/developer/products/atlas/mongodb_patronus_ai/) 为什么使用 MongoDB 用于 RAG 应用程序： - 实时响应能力： MongoDB 的架构确保了快速的数据交互，对于生成AI系统至关重要。 - 敏捷数据处理： 它的灵活数据模型支持快速的应用迭代，促进持续改进。 - 智能数据集成和查询： 支持语义搜索、全文搜索、地理空间查询和向量化查询，确保高效的数据检索。 - 安全性： 强调强大的安全控制，通过加密、基于角色的访问控制和审计功能保护敏感数据。 - 集成性： 设计成与任何云提供商、LLM和框架无缝集成，支持生成AI应用程序的动态需求。 ### 框架： Verba [Verba](https://github.com/weaviate/verba) 金毛寻回犬（Golden RAGtriever），是一款开源应用程序。它旨在为用户提供开箱即用的端到端、简化和用户友好的界面，用于检索增强生成（Retrieval-Augmented Generation，简称RAG）。用户只需简单几步，即可轻松探索数据集并提取洞见。无论是本地使用HuggingFace和Ollama，还是通过OpenAI、Cohere和Google等大型语言模型（LLM）提供商，操作都十分便捷。 ![Verba Architeture](images/verba_architeture_003_overview.png) ================================================ FILE: src/ai4se-2024-summary.md ================================================ # 2024 年落地 AI 辅助研发的实践心得：从工程、工具到未来展望 在过去的一年里，我大量的时间都花费在了 AI 辅助研发的调研、方案与落地实践上： - 年初，我们与国内大量互联网大厂一起，调研国内外 AI 辅助研发的现状，探讨了 AI 辅助研发的现状与未来。 - 我们新增了 AutoDev 的大量功能，如精准测试、自定义团队提示词、自定义智能体等。 - 与公司前 AI 部门，一起协作在客户侧，落地了 AutoDev 自动补全。 - 年中，创建了全新的 AISE 知识站点[aise.phodal.com](https://aise.phodal.com)，以记录我们的调研、实践与心得。 - 创建了下一代 AI IDE 插件 Shire，以探索 AI 辅助研发的新模式。 - 年末，在互联网客户侧，探索和落地了我们在 AI 辅助团队的方案 Team AI。 尽管，AI 辅助研发的现状并不是那么乐观，但是我们仍然看到了 AI 辅助研发的巨大潜力。结合这一年的实践中，我想分享自己的心得并吐槽一下国内的 AI 辅助研发工具的不上进。 ## 1. 短期内，别指望 AI 辅助研发能带来多大效果 商业化公司总是在一味鼓吹 AI 的短期效果，声称 AI 辅助研发可以提升 10%～30%+ 的效率。限于，我的开源工具和他们算是有利益冲突，这里就不点名了。 从个人的角度来说，在这些商业公司发布裁员消息之前，这些数据都是不可信的 —— 尽管我的观点是 AI 会淘汰一部分程序，也会有新的 AI 开发机会。 一如我在先前的文章里分享 Thoughtworks 之前的统计数据，AI 辅助研发的全链路提升在 2% 到 13% 之间，对于大部分已有项目的提升会在 5% 以下。原因不外乎，原有遗留知识不全、开发流程限制、自动化流程不成熟、AI 工具不成熟。但是，总体来说，如果我们还采取现有的流程， 不限于需求流程、开发流程、发布审批流程等。 但是，我们也要看到好的一方面： - 减少重复性工作。AI 对于规范、重复性的工作，还是有很大的帮助的。比如，已有规范体系完整下，它可以大量减少重复性工作，诸如于规范化的 开发文档、代码规范、测试用例等。 - 降低知识搜索成本。对于采用内网的开发的公司，诸如金融、通信等行业，模型内置的知识库就是一个非常好的搜索引擎。尽管它的准确性不高， 但是也过去相比，仍然具备非常大的优势 。 - 提升开发幸福感。通过自动完成一些繁琐的任务，AI 可以让开发者更加专注于创造性的工作，从而提高工作的满意度。 - 促进新技术学习。AI 可以作为一个学习工具，帮助开发者快速理解和掌握新的编程语言、框架和技术。 - …… 也因此，从成本的角度，能在内部跑上一个 70B+ 的模型，也能大大提升效率 —— 前提是配套上一些合适的 AI 插件和工具。 ## 2. 通过确定性提升准确性，是降低幻觉的关键 年初，我们在为某家商业银行设计 AI 辅助单元测试方案时，结合的是远程测试用例智能体 + AutoDev 的精准测试能力来生成。作为一个经常写测试的人，我发现 AI 生成的测试用例，有时候会有一些不准确的地方，诸如于：测试框架、数据准备、测试用例的边界条件等。这也是为什么在国内某商业 AI 辅助研发公司的竞品调研中， AutoDev 的测试能力是国内这些工具里最强的。因为，我们在测试用例生成上，是基于确定性的开发框架、测试框架、函数输入输出来生成，以进一步降低 AI 生成的幻觉可能性 —— 尽管依然会有一些幻觉，但是与普通的聊天型 AI 相比，我们的幻觉要低很多，并且接受率更高，可以做到一键生成。 那么，作为确定性的输入应该包含哪些？ - 工具上下文知识。诸如于测试框架、开发框架、编程语言等。 - 业务知识。来自于实现开发功能前，我们已经有的业务知识，如需求文档、设计文档等。 - 领域知识。结合不同行业特点，包含一些特定的领域知识，如金融、电商等，以生成更加符合业务场景的内容。 - 规范性知识产出。诸如于在测试用例生成时，测试人员编写的测试用例、测试数据等。 所以，与之对应的另外一个难点是，团队过去沉淀过多少领域知识、规范性知识产出，以及如何将这些知识转化为 AI 可以理解的知识。 ## 3. “手动介入” 是不可避免的提升关键上下文手段 在国外流行的 AI 辅助工具里，诸如于 Cursor、GitHub Copilot、Continue 等都支持了一些手工的上下文能力。用户可以根据自己的场景，有选择性地 添加一些上下文信息如文件等，以这种方式来提升上下文的确定性，避免 AI 生成的幻觉。而在 AI 问答场景下，则往往会通过二次确认的方式，来让用户确认 其意图是否正确，以避免出现错误的意图理解。 那么，有哪些高效地手动介入方式呢？ - 使用注释或特定的标记语言，在代码中添加上下文信息。如：在 AutoDev 中的聊天输入框使用变量，如: `$selection`, `language` 等方式。 - 通过交互式界面，实时提供反馈和修正，以引导 AI 生成更准确的内容。如：在输入区域中，可以选择相关的文件，或者额外加入文件等。 - 建立模板或模式，让用户可以根据特定的场景选择和应用。如：在 JetBrains AI 插件中，可以选择提交信息、测试等的模板，以生成更加符合场景的内容。 - 自定义提示词，以让团队加入特有上下文信息。如：在 Continue 中，用户可以自定义一些提示词和 action 等，来生成更加符合团队的内容。 - …… 与之相匹配的是，这些手动介入的方式存在大量的学习成本，以及如何让用户更好地理解这些手动介入的方式，以提升用户的使用体验。 ## 4. 构建统一的领域语言，依旧是 AI 辅助复杂应用的必经之路 四月，我们开始构建 AutoDev 的 VSCode 版本，在这个版本中我们加入了两个 @workspace 似的聊天问答策略，以帮助用户更好地理解 AI 的生成内容。策略一参考的是 辅助知识理解的 Bloop 项目，它采用的是假设性代码生成的检索方式；策略二参考是 GitHub Copilot 的关键词生成方式，将用户的问答转换为关键词来进行检索。 不论是哪种方式最后都会遇到挑战，一个项目的过去和现在的开发人员，并没有对如何命名达到一致的标准。这也就导致了 AI 并不总能很好地检索到相关的内容。 团队协作是靠共识来推动的，而共识是 AI 辅助团队的一个基础。在采用经典的软件工程方法，如领域驱动设计（DDD）等，我们是通过： - 定义领域模型。通过领域模型，将业务领域中的概念和规则抽象出来，形成一致的语言和概念体系。 - 创建统一的语言。确保团队成员在沟通和开发过程中使用统一的语言和术语，减少误解和沟通成本。 - 应用领域驱动设计原则。通过划分 bounded context（限界上下文），明确不同部分的职责和交互，构建清晰的应用架构。 这也就意味着，我们需要通过工程的方式告知 AI 工具，模型、语言和上下文边界，避免长上下文导致 AI 迷失的问题。 构建统一领域语言的过程并非一帆风顺，它需要团队的共同努力和持续的维护更新。反向的，这就意味着，我们需要借助 AI 进行知识的重构，诸如于生成合乎命名 的代码、重构出更好的领域语言等。 ## 5. 领域知识的检索是条条大路通罗马 七月，当我在休长期服务假时，我创建了全新的开源项目《AI辅助软件工程：实践与案例解析》：[https://aise.phodal.com/](https://aise.phodal.com/)。 在这个项目中，我收集了国内外的大量 AI 辅助研发工具，并进行了大量的调研与案例分析。在这个过程中，我发现了一个有趣的现象：AI 辅助研发工具的领域知识检索方式是多样的，对于不同的工具团队，采纳的方式也是不同的。 通常来说，罗马不是一天建成的，我们可以简单地把 AI 辅助厂商分为两类 —— 基于已有的开发工具增强的，如 SourceGraph、JetBrains 等；基于新的 AI 工具增强的，如 Cursor 等。在历史包袱不同的情况下，它们的领域知识检索方式也是不同的。 - 结构化知识依旧是首选。尽管有大量的工具可以将你的 PDF、Word 等转换为 markdown，再去拆分 chunk，但是这并不是最好的方式。不同文档的结构化方式不同， 你需要根据不同的文档类型，采用不同的结构化方式。结合 AI 先进行初步的清洗，是值得去尝试的一条路径。 - 充分利用数字化工具是不可或缺的。诸如 SourceGraph Codey 就可以借助已有存储的代码搜索能力进行检查。而诸如于如果你的目标更为宏大，诸如于基于 Gitlab 或者 Confluence 构建统一的内部 API 市场与查询，那么你得考虑先进行数字化的 API 管理，其次再进行 AI 的检索。 - 不同环节考虑不同向量化模型。如果只是简单的代码检索，可以考虑直接使用本地的模型。而如果是需要跨团队、跨项目的检索，那么你需要考虑使用 云端的模型。 在没有进行结构化之前，向量化是效率最低、效果最低的一种方式，但是实践成本最低的一种方式。实践成本最低，并不意味着成本最低，只是上手成本最低。 ## 6. 智能体的规划应该是基于模式拆解而来的 AutoCRUD 是我们探索 AI 编码能力极限的第一个尝试。在这个试验里，我们将 AI 与编码的 CRUD 模式相结合，从而让 AI 实现自动的编码流程。尽管，这并 非主流的 AI 自动编码方式，现今的智能体都是基于 AI 来进行规划的。而 AI 规划是基于通用的知识库， 也就是在你这个场景之下，Controller-Service-Repository 分层之下，它的编码方式应该就是这么去修改的。当你添加新的功能时，也应该采用类似的方式。 而当你在利用 AI 来进行任务拆解的时候，它也是基于已有学习到的模型进行的拆解。而一旦你的代码中有一些不符合模式的时候，它就会出现问题，比如你的代码中 可能同时存在多种编程范式。 - 模式应用到规则化提示词。模型理解主流的各种编程范式，自然而言，我们只需要根据不同的语言，动态生成适用于不同语言的模式即可。 - 清晰的任务描述是规划的基础。我曾经大量使用 GitHub Copilot CodeSpaces 来进行代码生成，它可以结合我在 GitHub issue 的描述，来生成代码。当你的任务描述不清晰时，它就会出现问题；而当你的任务描述清晰时，它的问题就会减少，但是也写不出可运行的代码。 - 集成环境依然是智能体的最好介质。尽管有大量的云端 AI 编辑器，但是缺少 IDE 中的 I（Integration 集成）能力，AI 就难以自动化进行任务，诸如于语法修复、运行测试、辅助进行 debug 等。 也因此，它需要拿到足够的上下文才能做好任务的拆解，而如我们所知的它总是拿不到足够的上下文。 ## 7. 面向 AI 的知识重构，是不可避免的路径 Unblocked 是我看到一个非常有创意的 AI 知识管理和消费工具 —— 它可以上你在 Web、macOS、JetBrain IDEs、VSCode、IM（如 Slack）上管理和运用你的知识。简单来说，它通常将来自 GitHub、Slack、Confluence、Linear 等平台的内容上下文整合进来，帮助您找到关于应用程序的准确答案。 对于企业来说，这就是一个非常值得参考的点：将 Jira、Gitlab.com/码云、Confluence、IM 等平台的内容整合进来，帮助团队更好地管理和运用知识。 再通过智能体或者 API 的方式，提供给 AI 工具，以帮助 AI 更好地理解团队的知识。诸如于 AutoDev 的智能体，就可以通过这种方式来应用企业提供的内部知识库。 十月，我们在探索 AI 辅助需求时，同样也遇到类似的知识挑战。知识工程是进一步提升 AI 辅助研发质量的关键，你需要考虑： - 开发 AI 工具原型是基础。知识工程需要考虑到消费端的需求，进而设计出合适的知识库结构、工具与 API 体系。当然，自上而下规划也是一个不错的选择。 - 持续知识的运营与管理是不可或缺的。高质量的语料、高质量的知识固然很重要，但是人们缺的并不是这些，而是如何构建反馈回路的运行机制，来让知识不断地更新。 不过，在你进一步重构之前，你需要考虑，什么才是知识？ ## 8. 交互的优化并不一定能解决模型的极限问题 在最近的模型发布中，我们可以看到模型似乎已经到了一个瓶颈，无法再继续大幅提升。这也就意味着，我们需要通过其他方式来提升效果，而不仅仅是依赖模型的提升。 诸如于：StreamDiff 是当前阶段主流的问答代码生成方式，即根据问题，从头生成代码，再以类似于 patch 的方式展现给用户。AI 每次总是尽可能的从头生成一遍代码，而不是通过真正的 patch 方式来生成。尽管，我们相信 patch 的计算方式终会实现，但是目前的 AI 模型还无法做得很好。 依赖于生成式 AI 的概率机制，它总是会有一些不确定性，而这种不确定性是无法通过交互来解决的。 - 非普适式的问题难以解决。诸如于 Intellij IDEA 插件代码，模型很难得到准确的答案 —— 10 个里有 9 个是错的；而类似于这一类的问题，又特别的多。 - 代码中的数值问题。模型很难得到准确的数值，诸如于你调用 AI 来对你的算法生成测试，它可以实现逻辑上的正确，但是数值上的正确需要你自己来验证。 - 顾尾不顾头的问题。典型的问题是，在 Java 代码中 AI 会无意多或者少 import 一些包，导致代码无法运行。 - …… 而这样的 corner case 问题，特别特别的多，大量的这一类问题都需要通过规则来解决，而不是通过模型来解决。又或者是诸如于 StreamDiff 换一种新的方式来解决。 ## 9. 先理解软件工程，再谈 AI 辅助研发 在这一年里，我发现很多工具和团队都在盲目追求 AI 辅助研发，但是却忽略了最基本的软件工程问题。我们经常看到这样的场景： - 需求文档写得很差，就想要 AI 来帮忙分析需求 - 代码没有任何文档和注释，就想要 AI 来理解代码 - 缺乏代码审查机制，就期望 AI 能自动发现所有问题 - 运维流程全靠手动，就期望 AI 能自动化运维 - 监控告警体系不完善，就想要 AI 来预测系统故障 - …… AI 辅助研发并不是万能的。如果你的团队连基本的软件工程实践都做不好，那么 AI 也帮不了你。相反，如果你的团队有良好的软件工程实践，那么 AI 就能够发挥更大的作用。换句话说，AI 辅助研发是在已有软件工程实践基础上的增强，而不是替代。它能帮助我们更高效地完成工作，但不能解决根本的工程问题。 因此，在探索 AI 辅助研发之前，我们应该考虑先建立完善的软件工程体系，同时： - 培养团队的全流程工程能力 - 建立规范的开发与运维流程 - 完善自动化基础设施 - 构建可度量的改进机制 只有在这些基础之上，AI 辅助研发才能真正发挥价值，帮助团队提升效率和质量。否则，再先进的 AI 工具，也只能是空中楼阁。 ================================================ FILE: src/ai4se-agentic-chat.md ================================================ # Agentic chat ## 示例 ### Sourcegraph - 深思熟虑，精准回答 Agentic Chat（自主智能聊天）能够主动收集、审查并优化相关上下文，以提供高质量、上下文感知的回答。它减少了用户手动提供上下文的需求，而是通过 Agentic Context Retrieval（自主上下文检索） 自动从你的代码库、终端甚至互联网获取并分析可用的上下文信息。 #### Agentic Chat 的核心功能 在启用 Agentic Chat 后，你的 AI 代码助手将拥有一整套上下文检索和优化工具，包括： - 代码搜索：执行代码搜索 - 代码库文件：检索代码库中的完整文件内容 - 终端：执行终端命令，以获取系统或项目相关信息 - Web 浏览器：在网上搜索实时信息 - OpenCtx：支持任何 OpenCtx 提供的上下文数据 ## Agentic Chat：深思熟虑，精准回答 **作者：Ado Kukic** **发布日期：2025 年 1 月 29 日** 当你指出 LLM（大语言模型）给出的回答大部分正确但缺少关键点后，它可能会回复你：“你说得对，正确的实现方式应该是……” 这种情况你是否经历过？如果是的话，你并不孤单。LLM 通过大量训练数据学习模式，以处理你的请求。然而，这种泛化往往优先考虑常识知识，而非特定领域的细节。如果你的提示词缺乏足够的上下文，LLM 可能会提供一个看似正确但缺乏关键细节的答案，从而影响任务的完成质量。 AI 代码助手需要更智能、更自主地运作。因此，我们今天正式为 Sourcegraph 用户推出 **Agentic Chat（自主智能聊天）** 。这一新功能能够主动收集、审查并优化相关上下文，以提供高质量、上下文感知的回答。它减少了用户手动提供上下文的需求，而是通过 * *Agentic Context Retrieval（自主上下文检索）** 自动从你的代码库、终端甚至互联网获取并分析可用的上下文信息。 --- ### **Agentic Chat 的核心功能** 在启用 Agentic Chat 后，你的 AI 代码助手将拥有一整套上下文检索和优化工具，包括： - **代码搜索**：执行代码搜索 - **代码库文件**：检索代码库中的完整文件内容 - **终端**：执行终端命令，以获取系统或项目相关信息 - **Web 浏览器**：在网上搜索实时信息 - **OpenCtx**：支持任何 OpenCtx 提供的上下文数据 ##### **生成单元测试** 单元测试生成是 AI 代码助手最常见的应用场景之一。开发者往往不喜欢写单元测试，虽然它重复但至关重要。 如果我们让 Cody 生成 `openExternalAuthUrl` 函数的单元测试，但 **没有提供任何上下文**，它仍然会生成测试代码，但正确性的概率不高。 在下图中，我让 Cody 生成 `openExternalAuthUrl` 函数的单元测试。由于没有指定文件或代码库，Cody 生成的测试尝试从一个 **不存在的 openExternalAuthUrl.ts 文件** 中导入函数。此外，测试代码也缺少函数的具体功能上下文。 **手动修正方法**：如果我手动指定了正确的文件 `AuthProviderSimplified.ts`，结果会更准确。 **Agentic Chat 方式**： 在 Agentic Chat 的帮助下，我可以直接发送相同的提示，而无需手动提供或引导 Cody。Agentic Chat **首先进行上下文检索**，找到 `openExternalAuthUrl` 函数所在的位置，然后提取相关文件，最终生成更高质量的单元测试，确保测试覆盖代码的实际功能。 ##### **上下文收集与优化** 让我们看另一个示例，演示 Agentic Chat 如何自动收集上下文信息。假设我包含了整个 `sourcegraph/cody` 代码库，并提出一个非简单的问题： > Agentic Chat 默认执行多少步反思（reflection）？ Cody 在获取了代码库后，选取了 **20 个文件** 作为上下文，并生成了一个初步答案，虽然有一定参考价值，但仍然未能完全回答我的问题。 在 **Agentic Chat 模式下**，即使提供了整个 `sourcegraph/cody` 代码库，它仍然会 **进行反思和分析**，优化上下文，最终发现 * *唯一需要的文件是 deepCody.ts**，从而生成准确的答案。 ##### **终端访问** Agentic Chat 还可以访问你的终端（需要用户授权）。如果 AI 认为需要执行某个终端命令来回答你的问题，它会请求你的许可，并利用终端输出提供更准确的解答。 **示例：统计仓库中的文件数量** - **没有 Agentic Chat**：用户需要手动执行命令并输入结果。 - **使用 Agentic Chat**：AI 自动生成命令，并在用户批准后执行，获取结果并提供解答。 终端访问还能用于更多场景，例如： - 运行 `npm audit` 并总结关键问题 - 获取代码仓库的最新变更摘要 - 其他项目或系统级任务 值得注意的是，**终端命令始终需要用户手动批准后才会执行**，以确保安全性。 ##### **Web 搜索** LLMs 训练数据通常滞后 **数月甚至数年**，而技术更新速度远超这个周期。因此，开发者常常遇到 API 版本过时的问题。 Agentic Chat 能够 **实时访问 Web**，在需要时执行搜索，获取最新数据。例如，我们可以让 Cody 查找 Twilio 的最新快速入门指南，并将其作为上下文，帮助我们将 API 集成到应用程序中。 ##### **OpenCtx 集成** Agentic Chat 还能与 **OpenCtx（开放上下文协议）** 结合，支持从 **Linear、Jira、Slack、Google Docs、Prometheus** 等工具获取上下文。 例如，假设我在 Sourcegraph 博客上看到有人报告了一个问题，但描述模糊。如果不提供上下文，Cody 可能会给出泛泛而谈的解决方案，甚至涉及我们不使用的技术栈。 **使用 Agentic Chat 和 OpenCtx 后**： - Cody 能精准识别该问题 - 提供相关细节，例如 **问题编号、名称** - 直接给出 **针对性的解决方案** ================================================ FILE: src/ai4se-design-principle.md ================================================ # AI 辅助软件工程：AI4SE 设计原则 > AI4SE（Artificial Intelligence for Software Engineering）是指将人工智能技术应用于软件工程领域，旨在通过 AI > 算法和工具改进软件开发、维护、测试和管理等环节的效率与效果。AI4SE 的核心目标是通过自动化与智能化技术，降低软件开发的复杂性，提升软件质量，并加快软件工程的进程。 ## 核心设计原则 在先前的《[LLM 优先的软件架构设计原则](https://aigc.phodal.com/llm-architecture.html)》一节中，我们思考了适合于 LLM 应用开发的设计原则。 在结合生成式 AI 构建软件领域的实践经验和案例分析后，我们总结了以下 AI4SE 设计原则： - **以人为本，AI 为辅** - **上下文智能化** - **数据驱动的闭环反馈** ### 以人为本，AI 为辅 AI 应被设计为提升人类生产力的工具，而非取代人类。在软件工程领域，AI 的作用是为开发者提供更多选择和更优质的决策支持。我们将 AI 辅助软件工程分为三个阶段/角色，分别是共航者（Co-Pilot）、共融者（Co-Integrator）和共促者（Co-Facilitator）。 ![](images/llm-as-levels.png) #### 共航者（Co-Pilot） - **减少重复性工作**：通过自动化重复和低价值任务，如数据录入和基础分析，AI 可以释放开发者的时间和精力。 - **辅助决策**：AI 能通过数据挖掘和分析，为开发者提供有价值的洞察和建议，帮助他们在复杂环境中做出更明智的选择。 - **实时反馈与优化**：在任务执行过程中，AI 能提供即时反馈与建议，帮助用户持续优化决策与行动方案。 #### 共融者（Co-Integrator） - **提高工作效率**：AI 能够优化和自动化工作流程，减少人为错误，提升整体效率。例如，在制造业中，AI 可以实时监控和调整生产线，从而提高生产效率与产品质量。 - **整合多源数据**：AI 可以从多个数据源中提取信息，并进行综合分析，为用户提供全面的视角和深刻的洞察。 - **促进跨领域协作**：AI 可以连接不同领域的知识和资源，促进跨学科和跨行业的合作与创新，推动技术与社会的进步。 #### 共促者（Co-Facilitator） - **增强学习与发展**：AI 可以作为学习工具，帮助人类持续提升技能和知识。通过智能辅导系统，AI 可以根据学习者的进度和需求，提供个性化的学习路径与资源。 - **组织协调**：AI 能通过全面的分析与预测，帮助组织优化资源分配、进度管理与风险控制，从而提升整体运营效率。 AI 通过这三个角色，超越了简单的工具定位，成为开发者不可或缺的合作伙伴。它不仅帮助我们解决当下的挑战，更为我们赋能，引领我们迈向更加创新与高效的未来。 ### 上下文智能化 有效的 AI 辅助研发工具，不仅仅是机械地执行简单的命令，它需要具备上下文感知能力。诸如于 SourceGraph 的文章《[Why context awareness is challenging for code AI](https://sourcegraph.com/blog/how-cody-provides-remote-repository-context) 》对些的深入探讨： - **人类与 AI 的上下文差异**：人类开发者依赖丰富且个性化的上下文知识，而 AI 则依赖于其训练数据中的通用上下文。这种差异意味着 AI 必须学会更好地理解和适应特定的任务环境。 - **增强 AI 的上下文感知**：为了提高 AI 的有效性，应通过引入与任务相关的上下文知识来增强其能力，使其能够更接近人类开发者的思维过程。 这种上下文不仅包括代码本身，还应包括开发者的习惯和项目的历史背景。 - **从繁琐到智能的转变**：虽然理论上可以通过手动复制粘贴代码来提供上下文，但这种方法既繁琐又违背了使用 AI 助手的初衷。目标应是让 AI 自动检索并利用相关上下文，从而提供更精准且实用的输出。 - **多层次的上下文支持**：根据任务的复杂性，AI 需要获得不同层次的上下文支持，从本地文件级别到仓库级别，再到远程仓库的广泛上下文。 每个层次的上下文都有助于提高 AI 的决策能力。 - **技术挑战与前景**：目前，许多 AI 工具可以处理本地文件的上下文，但当涉及到整个仓库，尤其是远程仓库的上下文时，仍然面临技术挑战。 这些挑战包括如何有效检索、分析和应用大量的代码和文档信息。 同时，AI工具应提供灵活的控制选项，以适应不同开发者的需求和工作方式。AI通过提供多种推荐选项，协助开发者依据个人偏好和习惯进行选择，进而提升工作效率。 通过减少对 AI 操作的硬性控制，并增强其上下文感知能力，可以构建更加智能且高效的开发环境。这使得AI真正成为开发者的得力助手。 ### 数据驱动的闭环反馈 成功的 AI4SE 不仅依赖于数据的驱动，还必须优先考虑开发者体验。通过构建闭环反馈机制，AI 工具能够不断适应和改进，以满足开发者的实际需求，实现高效、智能的开发支持。 #### 数据驱动与动态反馈 - **数据收集与分析**：AI 系统的性能依赖于高质量的数据。为了确保工具的有效性，AI 应自动化收集、分析并维护数据，为开发者提供有深度的洞察。这些数据可以包括代码库的变化、开发者的使用习惯以及项目进度等。 - **持续学习与优化**：AI 系统应具备持续学习和适应能力，能够根据实时更新的数据不断调整和优化其表现。这种自我优化的过程使 AI 工具能够随着项目的发展和用户需求的变化不断进步。 - **透明的决策机制**：AI 工具应向开发者清晰展示其决策依据，使用户能够理解 AI 的逻辑和推理过程。这种透明性不仅增加了工具的可信度，也帮助开发者在使用过程中更好地掌控和调整 AI 的输出。 #### 围绕开发者体验构建闭环反馈 - **实时反馈机制**：AI 工具应提供实时的反馈，帮助开发者在编写代码、调试和测试的过程中获得及时的支持。这种即时反馈能够让开发者迅速发现和解决问题，提升整体工作效率。 - **用户体验优化**：基于用户的实时反馈，AI 工具应不断优化其界面和功能，以提高易用性和用户满意度。通过迭代改进，工具可以更加贴合开发者的实际需求。 - **个性化建议与调整**：AI 工具应根据开发者的工作习惯和偏好，提供个性化的功能和建议。同时，工具应具备学习能力，能够根据反馈不断调整其行为和建议，确保其适应性和精准度。 - **无缝集成与协作**：AI 工具应无缝集成到开发者的工作流程中，减少上下文切换，提升团队协作的效率。通过这种集成，AI 不仅能为个体开发者提供支持，还能促进团队间的知识共享与合作。 通过数据驱动的决策和闭环反馈机制，AI4SE 工具能够不断适应和进化，为开发者提供更加智能、精准和高效的支持，最终助力他们在复杂的开发环境中实现卓越的成果。 ================================================ FILE: src/ai4se-github-ai-platform.md ================================================ # AI 辅助软件工程：GitHub 的 AI 平台工程赋能开发者 GitHub 的案例简单来说：围绕代码的开发、协作、构建为核心，以开发者体验作为度量体系 引自官方的定义 [GitHub AI 驱动的开发者平台](https://github.blog/2023-11-08-universe-2023-copilot-transforms-github-into-the-ai-powered-developer-platform/) ## 辅助编码：GitHub + GitHub Copilot 顶级发现显示，GitHub Copilot 有助于开发人员更快地编写代码，完成高达 46% 的代码，并使开发人员在工作中感到更加满足。 - [GitHub Copilot 数据](https://github.blog/news-insights/research/the-economic-impact-of-the-ai-powered-developer-lifecycle-and-lessons-from-github-copilot/) 表明：开发人员需要差不多 3 个月才能达到的代码接受率基线水平（30%） - 经验少的开发者更能受益 85% 的开发者在使用 GitHub Copilot 和 GitHub Copilot Chat 编写代码时，对代码质量更有信心。 [Research: Quantifying GitHub Copilot’s impact on code quality](https://github.blog/news-insights/research/research-quantifying-github-copilots-impact-on-code-quality/) ## [AI 增强的安全左移](https://github.blog/2023-11-08-ai-powered-appsec/) ![Images](images/github-security-shift.png) - 自动修复（autofix）静态代码问题 (结合 CodeQL 静态代码分析） - 密码扫描检测泄露的密码 - 生成自定义模式 - 正则表达式 相关文章： - [CodeQL team uses AI to power vulnerability detection in code](https://github.blog/2023-09-12-codeql-team-uses-ai-to-power-vulnerability-detection-in-code/) - [Multi-repository variant analysis: a powerful new way to perform security research across GitHub](https://github.blog/2023-03-09-multi-repository-variant-analysis-a-powerful-new-way-to-perform-security-research-across-github/) ### CodeQL 静态代码分析 ### Dependabot 自动化依赖更新 ## AI 辅助研发决策框架 [A developer’s second brain: Reducing complexity through partnership with AI](https://github.blog/2024-01-17-a-developers-second-brain-reducing-complexity-through-partnership-with-ai/) - 发现 1：认知负担确实存在，开发人员通过两种方式体验它。（太乏味了和这伤害了我的大脑"） - 发现 2：开发者渴望 AI 协助完成复杂任务，但我们必须把握好界限 - 发现 3：复杂任务由四个部分组成：理解（建构感知）、决策、行动计划、执行 - 发现 4：开发者对于在理解和制定行动计划方面，接受 AI 的协助。 - 发现 5：开发者对 AI 在决策或执行方面的自主性持谨慎态度。 [Social Integration of Artificial Intelligence: Functions, Automation Allocation Logic and Human-Autonomy Trust](https://link.springer.com/article/10.1007/s12559-018-9619-0) 形态框架： 1. **建构感知**。收集和综合形成任务背景的所有相关信息。 2. **制定行动**。定义执行任务的具体步骤和步骤的顺序。 3. **制定决策**。提出应该针对这个任务采取的措施。 4. **实现任务**。执行按照定义的顺序进行的步骤。 ## Copilot AutoFix [Found means fixed: Secure code more than three times faster with Copilot Autofix](https://github.blog/news-insights/product-news/secure-code-more-than-three-times-faster-with-copilot-autofix/) Copilot Autofix 是 GitHub Advanced Security (GHAS) 中一项新功能，利用 AI 技术帮助开发者更快地修复代码漏洞。它可以在开发者的拉取请求中自动生成修复方案 ，预防新漏洞进入生产环境，还可以处理现有代码中的漏洞，减轻安全债务。 主要特点包括： - **自动修复**：在检测到漏洞后，自动生成修复建议，开发者可以选择编辑、提交或忽略这些修复。 - **提升效率**：根据公开测试数据，使用 Copilot Autofix 修复漏洞的速度显著快于手动修复。 - **简化安全流程**：它帮助开发者，即使他们不是安全专家，也能轻松理解和修复安全问题。 - **保护开源项目**：GitHub 计划在 2024 年 9 月向所有开源项目免费提供该功能。 总的来说，Copilot Autofix 通过 AI 技术简化并加速了漏洞修复过程，帮助开发者更轻松地实现安全目标。 根据 2024 年 5 月至 7 月的公开测试版客户数据，Copilot Autofix 已经显著缩短了从漏洞检测到成功修复的时间： - 3 倍更快。开发者使用 Copilot Autofix 自动提交拉取请求中的修复方案的中位时间为 28 分钟，而手动解决同样的警报需要 1.5 小时。 - 7 倍更快。跨站脚本漏洞：22 分钟，而手动修复则接近三小时。 - 12 倍更快。SQL 注入漏洞：18 分钟，而手动修复则需要 3.7 小时。 ## 度量框架 [Space](https://queue.acm.org/detail.cfm?id=3454124) | | 满意度和幸福感 | 效率 | 活动 | 沟通和协作 | 效率和流程 | |----|--------------------------|----------------|------------------|-------------------|-------------| | 个体 | - 开发者满意度 | - 代码检视速度 | - 检视速度完成数量 | - 代码检视评分（质量或思考深度） | - 代码检视时长 | | | - 留存 | | - 编码时长 | - PR 合并次数 | - 生产力感知 | | | - 分配的代码检视满意度 | | - # 代码提交次数 | - 会议质量 | - 不受打扰 | | | - 代码审查的 | | - 代码行数 | - 知识分享，可发现性（文档质量） | | | 团队 | - 开发者满意度 | - 代码检视速度 | - # 完成的用户故事/需求点数 | - PR 合并次数 | - 代码检视时长 | | | - 留存 | - 交付的用户故事/需求点数 | | - 会议质量 | - 交接时长 | | 系统 | - 平台工程的满意度（如 CI、CD 流水线等） | - 代码检视速度 | - 部署频率 | - 知识分享，可发现性（文档质量） | - 代码检视时长 | | | | - 代码检视接受率 | | | - 系统中的速度/流动 | | | | - 平台用户满意度 | | | | | | | - 可靠性（正常运行时间） | | | | ================================================ FILE: src/ai4se-gitlab.md ================================================ # AI 辅助软件工程：Gitlab 赋能开发者的 AI4SE ![](images/gitlab-duo.png) GitLab Duo 是团队开发的一套AI驱动功能。它革新了我们的内部工程工作流程，极大提升了开发效率。作为狗粮政策和透明度的坚定拥护者， 我们愿意展示团队如何运用AI技术。这包括GitLab Duo的代码建议和聊天功能，它们每天帮助我们简化开发流程，减少手动操作，从而提高生产力。读者将了解到， 无论是技术密集型的工程团队，还是技术要求较低的团队（例如技术写作和产品管理），都从中获得了显著的好处。 ## GitLab Duo 内部使用案例 我们的团队已将 GitLab Duo 的众多功能整合到日常工作中。以下是 GitLab Duo 如何帮助他们完成日常活动的一些例子。 ### 总结和文档 **简化代码审查过程**：后台开发人员Gosia Ksionek展示了AI在她工作流程中的实际好处，通过使用 GitLab Duo 简化代码审查过程。她有效地利用GitLab Duo总结合并请求，使代码更改的审查变得更容易和更快速。除了总结合并请求外，Gosia还利用GitLab Duo回答编码问题并解释复杂的代码片段。这提高了她的生产力，帮助她更好地理解和管理复杂的代码库。通过这些演示，Gosia突出了GitLab Duo如何显著改善开发过程中的效率和清晰度，使其成为开发人员不可或缺的工具。 **压缩评论线程**：扩展软件开发副总裁Bartek Marnane使用 GitLab Duo 将冗长的评论线程压缩为简明摘要，确保在更新问题描述时捕捉到所有相关细节。 **创建新文档**：数据科学部门产品组经理Taylor McCaslin利用 GitLab Duo 为GitLab Duo本身创建了新文档，展示了一个提高清晰度和一致性的元用例，并大大减少了记录新功能所需的时间。 **编写发布说明**：产品规划高级产品经理Amanda Rueda使用GitLab Duo编写简短而有影响力的发布说明，突出更改及其对用户的价值。通过使用如下面这样精心设计的提示，Amanda增强了她的工作流程，确保每个发布说明都是清晰、简洁且以用户为中心，提升了整体沟通和用户体验： “请为此更改创建一个两句话的摘要，用于我们的发布说明。语气应为对话式，并使用第二人称。摘要应包括问题或更改的描述，并与我们为你，用户，创造的价值相关联。” 以下是与 GitLab Duo 共同创建的一些发布说明的示例： - 扩展了路线图的排序选项 - 现在可以使用里程碑和迭代来增强问题板的清晰度 - 设计管理功能扩展到产品团队 **优化文档站点导航**：资深技术写作员Suzanne Selhorn利用 GitLab Duo 通过提供基于工作流的页面顺序来优化左侧导航。Suzanne向GitLab Duo提供了功能列表，生成了最佳顺序，并更新了左侧导航以匹配。 GitLab Duo 还比使用传统手动方法更快地起草了入门文档。 ### 目标设定和团队对齐 **起草和完善OKR**：代码审查后端工程经理François Rosé发现GitLab Duo聊天在起草和完善OKR方面非常有价值。通过更清晰和有效地表达目标，François增强了目标设定和团队对齐。使用聊天，François确保每个OKR都是明确的、可执行的，并与团队的目标保持一致，从而提高了整体团队表现和凝聚力。以下是他使用的一个示例提示： ```bash 这是我打算创建的一个OKR： 目标：回顾回顾会议，促进团队繁荣 KR：测量100%团队成员的回顾满意度 KR：识别3个异步回顾的改进点 KR：实施1个改进 请提供如何改进这个目标和这些关键结果的直接反馈。 ``` **简化招聘和招聘流程**：聊天帮助前端工程师Denys Mishunov制定了更新技术面试候选人电子邮件模板的明确简洁的文本。团队合作优化了沟通，以确保候选人获得所有必要信息，并使用合并请求进行。这个例子展示了AI工具在招聘流程中增强沟通的实际应用。 ### 事件响应和配置 **总结生产事件**：现场可靠性工程师 Steve Xuereb 使用 GitLab Duo 总结生产事件并创建详细的事件回顾，从而简化文档编制过程。 **创建样板 `.gitlab-ci.yml` 文件**：Steve还使用聊天创建样板 `.gitlab-ci.yml` 文件，显著加快了他的工作流程。聊天作为一个有价值的伙伴，提出建议。此外，代码解释提供了详细的答案，在事件发生时很有帮助，提 高了他的生产力和对代码库的理解。 ### 代码生成和测试 **全栈开发**：高级前端工程师 Peter Hegman 一直在使用代码建议进行 JavaScript 和 Ruby 开发。这突显了代码建议已成为开发人员跨越完整技术栈的强大工具。 **生成Python脚本**：Denys 进行了一个使用 GitLab Duo 完成非 GitLab 任务的实验。这个例子突显了我们的AI工具在典型软件开发任务之外的灵活性和实用性。 观看Denys如何使用 GitLab Duo 生成 Python 脚本以获取内容数据并将其存储在本地： ### 研究和支持 **生成测试源代码**：高级开发者倡导者 Michael Friedrich 使用 GitLab Duo 为 CI/CD 组件生成测试源代码。 以这种方式使用 GitLab Duo 有助于确保代码的一致性、良好的文档记录，并与我们的最佳实践保持一致。 **简化研究任务** ：我们的团队成员在有关于 GitLab 功能的问题时，经常求助于聊天，简化他们的研究和支持任务。Michael分享说，“当我有关于GitLab功能的问题时， 我会默认使用聊天，而不是打开 100 个浏览器标签。这种工作流程帮助我高效地在我们的社区论坛上协助用户。例如，我最近使用这种方法帮助一个用户进行SSH部署。” 使用聊天不仅节省时间，还提供快速、准确的信息，增强了我们为社区提供的支持。 ### 功能测试 **测试新功能**：我们的工程师使用 GitLab Duo 测试新的功能，如代码建议中的Markdown支持。我们的一个团队成员指出，“我需要测试代码建议中的Markdown支持，以便在VS Code中编写博客文章和GitLab文档。我看到它已合并到17.0版本。”通过内部测试这些功能，我们确保它们在发布前达到我们的质量标准。 ### 理解外部代码库 **介绍外部项目解析功能**：GitLab Duo的 `/explain` 功能，在帮助理解导入 GitLab 的外部项目方面极为有效。这一功能在 Michael 最近与开源专家 Eddie Jaoude 的直播中得到了重点介绍。Michael 表示：“我利用 `/explain` 功能来深入理解外部项目的源代码。我曾在直播中分享这一思路， 它有助于我们更好地了解开源项目及其依赖关系。”这一功能对于开发者而言，在快速掌握不熟悉的代码库及其依赖关系方面显得尤为珍贵， 极大地提升了他们的工作效率和代码理解能力。 ## 其它 相关文章： - [Developing GitLab Duo : How we are dogfooding our AI features](https://about.gitlab.com/blog/2024/05/20/developing-gitlab-duo-how-we-are-dogfooding-our-ai-features/) ================================================ FILE: src/ai4se-google-dev-activity-driven.md ================================================ # AI 辅助软件工程：Google 开发者活动驱动的 AI 赋能 > DIDACT (Dynamic Integrated Developer ACTivity) 是一种用于训练大规模机器学习（ML）模型的软件开发方法。与传统只使用完成代码的方式不同，DIDACT > 创新的地方在于，它使用软件开发过程本身作为模型的训练数据来源。这意味着模型不仅能看到开发者在工作时所见的上下文，还能学习他们所采取的行动， > 从而更好地理解软件开发的动态过程，并与开发者的实际工作方式对齐。 ## Google DIIDACT 框架：动态集成开发人员活动 Google 在内部探索了[LLM for Dev Activity](https://research.google/blog/large-sequence-models-for-software-development-activities/) 方式， 以提升开发人员效率： ![DIDACT](images/google-didact.png) ### DIIDACT 框架：[Smart Paste](https://research.google/blog/smart-paste-for-context-aware-adjustments-to-pasted-code/) **智能粘贴**是谷歌开发的一种内部工具，旨在通过自动调整粘贴代码来优化编码工作流程。这个工具利用生成式人工智能来创建上下文感知的修改，从而提高代码开发的效率。以下是其主要特点和优势的概述： 1. **自动化的粘贴后调整**：智能粘贴分析周围的代码环境，并对粘贴的代码进行必要的修改，比如添加缺失的语法、重命名变量或更改类型。这减少了粘贴代码后手动调整的工作量。 2. **用户行为洞察**：谷歌的单一代码库分析显示，大约有25%的粘贴操作会立即被修改，这可能会打断编码流程。智能粘贴通过预先进行这些常见调整，试图最小化这种中断。 3. **生成式人工智能集成**：该工具利用先进的人工智能模型（如DIDACT），预测并实现必要的变更，确保粘贴的代码与现有代码库平滑集成。 4. **高采纳率和性能**：在大约40,000名工程师的研究中，智能粘贴被使用于所有粘贴操作的6.9%，其中42.5%的建议被接受。这表明工作流效率有显著提升。 5. **训练和校准**：该模型使用谷歌单一代码库中的粘贴后编辑数据进行训练，包括不需要进行编辑的情况。这个全面的数据集帮助模型学习何时建议变更以及何时保持代码原样。 6. **用户体验设计**：该工具旨在以用户友好的方式提供高置信度的修改建议。建议会以视觉提示显示，并在特定时间内自动丢弃，以避免打断用户的工作流程。 7. **内联差异预览**：为了保持用户控制并清晰显示建议的变更，使用内联差异预览。这在编辑器中直接突出显示插入和删除的片段，使用户可以通过简单的快捷键接受建议。 8. **未来增强计划**：计划包括探索模型在复制粘贴交互之外的能力，并重新审视针对小而高置信度变更的自动应用模式。 智能粘贴代表了人工智能辅助编码工具的重大进步，减少了代码集成所需的手动工作，并提高了开发人员的整体生产力。 ### DIIDACT 框架：[Code Review](https://research.google/blog/resolving-code-review-comments-with-ml/) 代码更改审查是规模化软件开发过程中的关键部分，占据了代码作者和代码审查者大量的时间。在这个过程中，审查者检查提议的代码，并通过用自然语言撰写的评论向作者提出代码更改请求。 ![](images/suggestion-filter-funnel.png) ### DIIDACT 框架：[AutoCommenter](https://arxiv.org/abs/2405.13565) Paper：[AI-Assisted Assessment of Coding Practices in Modern Code Review](https://arxiv.org/abs/2405.13565) 现代代码审查（Sadowski等人，2018年；Rigby和Bird，2013年）（与整体代码审查（Fagan，1976年）相比）多年来在开源和工业环境中有机地发展壮大。已经形成了一组常见的同行评审标准（Rigby和Bird，2013年；Rigby等，2012年；Bacchelli和Bird，2013年），其中包括编码最佳实践。许多公司、项目甚至编程语言都正式定义了这些标准，以" 样式指南"的形式（goo，2024；lin，2024；pyt，2024；rus，2024），通常涵盖以下方面： - 格式化：行限制、空格和缩进的使用、括号和大括号的放置等； - 命名：大写、简洁、描述性等； - 文档：文件级、函数级和其他注释的预期放置和内容； - 语言特性：在不同（代码）上下文中使用特定语言特性； - 代码习惯：使用代码习惯来提高代码清晰度、模块化和可维护性。 开发人员通常对现代代码审查流程报告高度满意（Sadowski等人，2018年；Winters等人，2020年）。其中一个主要好处是对于不熟悉代码库、特定语言特性或常见代码习惯的代码作者来说，这是一个学习经验。在审查过程中，专家开发人员教育代码作者使用最佳实践，同时审查（并学习）代码贡献及其影响。 静态分析工具如linters（Johnson，1977年）可以自动验证代码是否符合某些最佳实践（例如格式化规则），有些工具甚至可以自动修复违规。然而，细致的指导方针或带有例外的指导方针在整体上很难完全自动验证（例如命名约定和对旧代码中合理偏差的正当性），有些指导方针根本无法通过精确规则捕捉（例如代码注释的清晰性和具体性），而是依赖于人类判断和集体开发者知识。因此，一般期望人类审阅员检查代码变更是否违反最佳实践。 代码审查过程的最大成本是所需的时间，尤其是来自专家开发人员的时间。即使有了显著的自动化措施，并尽可能保持流程轻量化，开发人员每天仍然可以轻松花费数小时进行此任务（Sadowski等人，2018年）。 机器学习的最新进展，特别是大型语言模型（LLMs）的能力，表明LLMs适合于代码审查自动化（例如（Tufano等人，2024年，2022年；Hong等人，2022年；Li等人，2022b，a；Thongtanunam等人，2022年））。然而，在规模化部署端到端系统的软件工程挑战仍未被探索。同样，缺乏对这些系统整体效力和用户接受度的外部评估。 本文探讨了部分自动化代码审查流程的可能性，特别是检测最佳实践违规，从而为代码作者提供及时反馈，使审阅员能够专注于整体功能。具体而言，本文报告了我们在Google工业环境中开发、部署和评估AutoCommenter——一种自动化代码审查助手的经验，目前每天由数万名开发人员使用。 ### DIIDACT 框架：[Build Repair](https://research.google/blog/safely-repairing-broken-builds-with-ml/) 我们在集成开发环境中展示了修复，并对这一功能进行了控制实验。这个实验显示，在多个生产力衡量指标上都取得了统计上显著的增益，包括代码更改数量增加了 2%。 这些增益不仅仅是为了它们自身的好处，而且通过自动化消除了开发者的重复劳动，为他们提供更多时间进行创造性问题解决。这通过消除障碍促进了专注， 从而让开发者能够更长时间保持他们的工作流状态。实际上，我们现在观察到，在一个月内遇到构建中断的用户中，约有34%最终采纳了这种由 ML 建议的修复方案。 ![Google Buildfix](images/google-build-fix.png) 为了评估通过我们的修复引入不正确甚至危险代码的风险，我们检查了回顾性的安全性和可靠性相关指标，包括： - 变更列表回滚率：生产中的问题通常通过回滚引入错误的变更列表来解决。 - 新的检测工具失败率：谷歌运行的检测工具可以检测和标记单元测试和模糊测试中的内存损坏或泄漏问题；例如AddressSanitizer、MemorySanitizer和GWP-Asan。 我们在使用构建修复的变更列表和未使用的变更列表之间监测了这些指标，发现没有可检测的差异。 ### DIIDACT 框架：[代码迁移](https://research.google/blog/accelerating-code-migrations-with-ai/) 多年来，谷歌一直使用专门的基础设施来执行复杂的代码迁移。该基础设施使用静态分析和如 [Kythe](https://kythe.io/) 和 [Code Search](https://abseil.io/resources/swe-book/html/ch17.html) 等工具来发现需要更改的位置及其依赖关系。然后使用如 [ClangMR](https://clang.llvm.org/docs/RefactoringEngine.html) (Clang’s refactoring engine)等工具进行更改。 我们将迁移过程概念性地分为三个阶段： - 确定需要修改的代码库位置 - 编辑生成和验证 - 更改审查和发布 虽然这些阶段中的每一个都受益于 AI，我们主要关注第 2 阶段。 为了生成和验证代码更改，我们利用了在谷歌内部代码和数据上微调过的 Gemini 模型版本。 每次迁移需要以下输入： - 一组文件和预期更改的位置：路径 + 文件中的行号 - 一到两个描述更改的提示 - [可选] 少量示例，以确定文件是否确实需要迁移 多阶段代码迁移过程的示例执行。 ![](images/Google-AI_code_migrations.jpg) 用户提供的文件位置通过预先存在的静态工具和人工输入的组合进行收集。我们的迁移工具包会自动扩展这组文件，添加其他相关文件，包括：测试文件、接口文件和其他依赖项。 这一步骤尚未由 AI 驱动，但使用了符号交叉引用信息。 在许多情况下，用户提供的迁移文件集并不完美。由于过滤输入列表可能很繁琐，一些文件可能已经部分或完全迁移。因此，为了避免冗余更改或在编辑生成过程中混淆模型， 我们提供了少量示例，并要求模型预测文件是否需要迁移。 编辑生成和验证步骤是我们发现自动系统最有益的地方。我们的模型在谷歌的单体代码库和流程数据上按照 DIDACT 方法进行了训练。在推理时， 我们用自然语言指令以及模型的一般指令对每一行预计需要更改的地方进行标注。在每次模型查询中，输入上下文可以包含一个或多个相关文件。 模型然后预测文件之间的差异（diff），并且可以更改相关部分，以确保最终代码正确。 ## 其它 相关文章： - [AI in software engineering at Google: Progress and the path ahead](https://research.google/blog/ai-in-software-engineering-at-google-progress-and-the-path-ahead/) ================================================ FILE: src/ai4se-lifecycle.md ================================================ # AI 辅助软件工程：软件生命周期驱动的 AI4SE 生成式 AI 并非银弹。 当我们谈及 AI 辅助软件工程时，我们期望的是 AI 能在改善即有流程的现状，同时提供更多的可能性，诸如于： 1. **自动代码修复**： 利用 AI 技术分析代码并提出修复建议，帮助开发者更快速地解决问题。 2. **智能代码补全**：类似于 GitHub Copilot 和 TabNine，根据上下文预测开发者可能编写的下一行代码，大大提高编码效率。 3. **代码重构**： 识别出需要重构的代码片段，并提供重构建议，并应用代码重构。 4. **单元测试生成**： 自动生成单元测试，帮助开发者确保代码的正确性和可靠性。 5. **代码合并和冲突解决**：帮助自动化代码合并过程，并智能解决合并冲突。 6. **性能优化建议**：学习历史数据和性能模式，帮助开发者识别出影响性能的代码部分，并提供具体的优化方案。 7. **安全漏洞检测**： 检测代码中的安全漏洞，并提供修复建议。 8. **代码审查助手**： 自动检测代码中的问题并提出改进建议，提供详细的审查报告，帮助审查人员更高效地进行代码评审。 9. …… 但是，并非所有的环节都需要结合 AI、适合 AI，有些环节反而会因为 AI 的引入而增加复杂性，降低效率。 ## AI 要解决什么问题？软件工程面临的挑战 我们总期待生成式 AI 能解决一部分软件开发中的问题，但是限制我们软件交付速度的往往不是技术，而是人。人与人之间的协作、人对需求的理解、人对已有代码的理解等等。 理想情况下，只有人被取代了，那么问题才会消失。可是，AI 并不能代替你去坐牢，所以最后还是需要人来做决策。 ### 生命周期内的挑战 完全按照某一特定的开发流程来开发软件是不现实的。在组织中，我们总是允许每个团队根据自己的现状，来适当地改造软件开发流程。也因此，每个团队所面临的 挑战也是不同的。诸如于，我们典型的分析方式是根据软件生命周期的不同阶段来审视和分析。 如下是由生成式 AI 生成的软件生命周期的挑战： 1. 需求分析阶段 - 需求变更和管理：需求往往会在项目生命周期中发生变化，不良的变更管理可能导致项目延迟和成本增加。 - 需求不完整或不清晰：如果需求定义不清晰或不完整，可能会导致后续阶段的问题，如设计和开发时的误解或错误。 2. 设计阶段 - 架构设计挑战：设计阶段需要考虑系统架构、模块化、性能和可扩展性，这些方面的决策会对整个项目的成功产生深远影响。 - 设计与需求的一致性：确保设计方案与需求规格的一致性，以及如何适应可能的变更。 3. 开发阶段 - 技术选型和工具挑战：选择适合项目需求的技术栈和工具集合是一个重要的决策，可能会影响到开发进度和产品质量。 - 团队协作和沟通：大型项目中，多个开发者的协作和沟通是关键，特别是在分布式团队或跨时区工作的情况下。 4. 测试阶段 - 全面性测试覆盖：确保测试用例覆盖所有功能和边界情况，以及如何处理复杂系统的集成测试。 - 自动化测试和持续集成：实现自动化测试并结合持续集成可以显著提高软件质量和开发效率。 5. 部署阶段 - 部署流程自动化：设计和实施可靠的部署流程，包括配置管理、版本控制和部署自动化，以降低部署错误的风险。 - 环境一致性和兼容性：确保在不同环境（开发、测试、生产）中软件的一致性和兼容性，尤其是涉及复杂的分布式系统时更为关键。 6. 维护阶段 - 问题追踪和修复：确保能够及时发现和解决生产环境中出现的问题，需要有效的问题追踪和处理流程。 - 版本管理和更新：管理和维护软件的不同版本，包括安全更新和功能更新，以及如何进行版本回退和紧急修复。 总的来说，这些挑战是非常常见且具体的，放到一个大型组织中，上述问题几乎也是非常相似的。当你进行详细的分析之后，你会发现，AI 只能解决一部分问题， 并且经典的软件工程方法和工具也能解决一部分问题，当然了最后所有的问题都是人的问题。 ### 其它挑战 除此，我们还会遇到一些外部的挑战，这些挑战可能会对软件开发团队的工作产生影响，包括但不限于： 1. 项目管理和进度控制 - 资源管理与分配：确保项目所需资源（人力、技术、资金）的有效管理和分配，以支持软件开发的不同阶段。 - 风险管理：识别、评估和管理项目中可能出现的风险，包括技术风险、市场风险和组织风险，以最小化其对项目目标的负面影响。 2. 质量保证和标准遵循 - 质量管理系统：实施和维护适当的质量管理系统，以确保软件质量达到用户期望和行业标准。 - 安全性和合规性：确保软件在设计、开发和部署过程中符合安全标准和法规要求，特别是涉及用户数据或敏感信息的应用程序。 3. 项目间协作 - 跨团队协作：确保不同团队之间的有效沟通和协作，特别是在大型和分布式团队的情况下，以确保整体项目目标的一致性和实现。 4. 遗留系统和技术债务 - 云原生和微服务架构：这些技术推动了软件开发的灵活性和可扩展性，但也带来了新的挑战，如服务治理、服务发现和跨服务的数据一致性。 - DevOps 实践：自动化部署、持续集成和持续交付（CI/CD）的实施，以及开发团队与运维团队之间协作的增强，要求文化和工具的整合。 - 容器化技术（如Docker）：管理和部署容器化应用程序的复杂性，以及与传统部署方式的集成和过渡。 与上述的软件生命周期挑战相比，这些外部挑战更多地涉及到组织和行业层面的问题，更难通过 AI 来解决。 ## 应用 AI 之前：经典工具可行吗？ 现阶段，我们（包含笔者在内）将 AI 当成一把锤子，看到的问题都是钉子（锤子效应），尝试用 AI 来解决所有问题。但是，AI 并不是银弹，也并不是万能的。 而过去的几十年里，在软件工程领域已经积累了足够的经验和知识，形成了一系列经典的工具和方法，用于解决软件开发和维护过程中的各种问题。 这些工具和方法包括代码质量检查、架构设计、自动化测试、安全测试等，已经在实践中得到了广泛应用。这些工具和方法包括但不限于： - SonarQube：用于代码质量检查和静态代码分析的工具，可以帮助开发团队发现和修复潜在的代码问题。 - ArchGuard：用于架构设计和评估的工具，可以帮助团队设计和优化系统架构。 - ArchUnit：用于架构单元测试的工具，可以帮助团队验证架构设计的一致性和正确性。 - EvoSuite：用于自动生成测试用例的工具，可以帮助团队提高测试覆盖率和质量。 - Checkstyle：代码风格和质量检查工具，可配置规则来确保代码符合指定的编码标准。 - FindBugs：用于Java代码的静态分析工具，帮助开发者发现常见的编程错误和潜在的安全漏洞。 - OWASP Zap：开源的安全测试工具，用于查找Web应用程序中的安全漏洞和漏洞利用。 - …… 除此，还有诸如 SAST (Static Application Security Testing) 和 DAST (Dynamic Application Security Testing) ：这两种测试方法结合了不同的工具和技术，分别用于静态和动态地评估应用程序的安全性。 - Facebook's Aroma：一个代码推荐系统，可以从大型代码库中提取代码模式，并为开发者提供优化建议。 - SourceGraph：一个代码搜索和导航工具，可以帮助开发者快速定位和理解代码库中的代码片段。 - …… 当然了诸如此类的工具和方法，也需要大量的开发成本。 ## 现在，考虑一下 AI 要解决什么问题？ 现在，我们再考虑一下 AI 能不能解决问题？以及 AI 要解决什么问题？针对于不同的场景，方案是不同的。我们分析了市面上的主要 AI 工具，发现 AI 工具 的两种主要实现策略： - 增强现有工具。诸如结合 AI 通过分析大量的代码库和历史数据，生成更智能和精确的代码检查规则，帮助开发团队及时发现潜在的错误和漏洞。 - AI 原生的软件工程工具。市面上的工具如 GitHub Copilot、Testim.io、Snyk（DeepCode）等，都是基于 AI 技术构建的新型软件工程工具，可以帮助开发团队提高生产力和质量。 由于生成式 AI 存在的幻觉问题，我们更倾向于增强现有工具，而不是完全替代。 ### 实现策略：增强现有工具 在代码质量等场景，已经有大量的团队尝试直接将所有的上下文发给 AI，然后交由 AI 来处理。这种方式不仅是低效的，而且也会导致 AI 无法真正发挥作用。 在这些场景中，类似的方案应该是： - 生成检查规则：像 SonarQube 和 Checkstyle 这样的工具可以利用AI技术生成更智能和精确的代码检查规则。AI 能识别出更有效的代码质量问题，并提出更具针对性的检查建议，帮助开发团队及时发现潜在的错误和漏洞。 - 误判处理：在静态代码分析中，经典工具有时会误判某些代码片段或模式。AI 可以识别这些误判，并提供更准确的判断或建议，帮助开发团队减少误报，节省审查和修复的时间。 - 辅助边界测试用例生成：工具如 EvoSuite 用于自动生成测试用例，结合AI技术可以更快速地生成全面且有效的测试覆盖。AI能够分析代码逻辑和历史的错误模式，生成更具预测性和全面性的测试用例，帮助团队提高软件质量和稳定性。 - 辅助架构治理边界：像 ArchGuard 和 ArchUnit 这样的工具在架构设计和测试中发挥重要作用。AI 通过分析大量系统使用数据和性能指标，提供优化架构的建议和模型，帮助团队设计更高效、可靠和可扩展的系统架构。 - …… 在诸如于 CodeQL 和 SonarQube，结合领域的 AI 模型或者 RAG，我们可以生成对应的代码检查规则，而不是人工编写。随后，再结合 AI 来帮助人们处理过程中的误差问题。 ### 实现策略：AI 原生的软件工程工具 在特定的小流程中，AI 原生的软件工程工具可能会更加适用。这些工具通常是基于 AI 技术构建的新型软件工程工具，可以帮助开发团队提高生产力和质量。诸如于： - GitHub Copilot：一个基于 OpenAI Codex 的代码补全工具，可以根据上下文自动生成代码片段，提高开发效率。 - Testim.io：基于AI的端到端测试自动化工具，帮助开发团队快速创建、执行和维护测试用例。 - Snyk（DeepCode）：一个AI驱动的代码审查工具，通过机器学习算法检测代码中的错误、漏洞和潜在问题，并提供修复建议。 - …… 它们的特别是针对于特定的场景，如测试、代码、质量，构建专用的模型和工具，以真正释放 AI 的潜力。 ================================================ FILE: src/ai4se-sql.md ================================================ # SQL 生成 ## 度量 Text2SQL 榜单：[Spider](https://yale-lily.github.io/spider) ## 示例 ### Full Rag：Hyperpersonalization 应用 Tecton的方法： - 基础层（Level 0）： 仅限于基本的检索，没有额外的上下文信息。 - 批处理上下文（Level 1）： 使用历史数据（例如之前的旅行记录、喜爱的活动）。Tecton通过管理数据管道和历史数据集来简化构建此类上下文的过程。 - 批处理 + 流数据上下文（Level 2）： 整合实时用户数据（例如最近的搜索、会话交互）。这一阶段提供更及时的推荐，但实施成本较高。 - 批处理 + 流数据 + 实时上下文（Level 3）： 引入实时数据，如实时搜索查询和应用程序互动。挑战包括整合第三方数据源以及平衡速度与成本。这一层级提供高度相关的实时推荐，还可以包括基于反馈的调整。 Level ![](images/level0-no-context.png) ![](images/level1-batch-context.png) ![](images/level2-streaming-context.png) ![](images/level3-full-context.png) ### RAG2SQL：Vanna [Vanna](https://github.com/vanna-ai/vanna) is an MIT-licensed open-source Python RAG (Retrieval-Augmented Generation) framework for SQL generation and related functionality. ![](images/rag-to-sql.webp) [Vanna: The Supercharged Text-to-SQL Tool All Data Scientists Were Looking For](https://blog.dailydoseofds.com/p/vanna-the-trainable-text-to-sql-agent) #### Function RAG **Function RAG（检索增强生成）** 是 Vanna.ai 引入的一项创新功能，旨在改进 SQL 生成。以下是详细说明： #### 什么是 Function RAG？ Function RAG 将传统的“问题-SQL”对转换为可重用的模板或函数，这些模板由大语言模型（LLM）调用以生成 SQL 查询和相关的后处理代码（如图表代码）。LLM 的作用是选择合适的 SQL 模板并填充必要的参数，从而实现更一致且更快速的 SQL 生成。 #### Function RAG 的主要特点： 1. **基于模板的 SQL 生成**：通过使用从训练对创建的模板，Function RAG 确保生成的 SQL 既准确又相关。 2. **增强的安全性**：这种方法减少了提示注入和提示转义等漏洞，使 SQL 生成过程更加安全。 3. **用户特定查询**：用户可以在查询中包含特定信息，如用户 ID，且不会有数据被覆盖的风险，从而安全地实现个性化查询。 4. **集成图表代码生成**：Function RAG 可以在一次请求中生成 SQL 及相应的可视化代码（如 Plotly 代码）。 5. **多语言支持**：通过 GraphQL API 访问，Function RAG 可以在各种编程语言中使用，不仅限于 Python，便于集成到不同的后端，如 Ruby on Rails、.NET 等。 #### 使用示例： - **查找函数**：使用 `vn.get_function(question=...)` 查找并调用适当的函数，由 LLM 填充参数。 - **限定到特定用户**：使用 `vn.get_function(question=..., additional_data={"user_id": ...})` 确保查询限定到特定用户，通过确定性地设置 `user_id` 参数。 - **创建新函数**：可以手动使用 `vn.create_function(question=..., sql=..., plotly_code=...)` 创建函数，或者通过支持自动从问题中提取参数的 Web 应用创建函数。 #### 何时使用 Function RAG： Function RAG 适用于终端用户频繁提出类似问题的场景。它允许进行受控和批准的分析，确保呈现的数据可靠且正确。此功能特别适合内部业务用户或 SaaS 应用程序。然而，对于更多新颖和多样的分析，传统的 SQL 生成功能可能更合适。 ![](images/functions-browse.png) ### Uber QueryGPT [QueryGPT – Natural Language to SQL Using Generative AI](https://www.uber.com/en-IN/blog/query-gpt/) ![QueryGPT](https://lh7-rt.googleusercontent.com/docsz/AD_4nXctJlWIn-wn89ptfWpK2OrhH9sVIkP5OqSthEr21ZoybaECaxE5GATRUNJX8ElX1ODGz1N2JHcg0sYjN1QXIi9T-_Ex6VjVUunGJ8s5SW2D5gaEUme4Skh3NrVqjmIazQZPJ17XhJ2JJwo3FfqpLh8JD9j4?key=FDiTashaNIm84IIOQgmW9w) Uber 开发了 **QueryGPT**，一个可以使用自然语言提示生成 SQL 查询的工具。 #### **核心目标** 该工具旨在通过简化 SQL 查询的编写过程来提高生产力，因为传统的 SQL 查询需要深入了解 SQL 语法和 Uber 的内部数据模型。 #### **工作原理** QueryGPT 利用 **大语言模型（LLM）**、**向量数据库** 和 **相似性搜索**，将用户的英语问题翻译成复杂的 SQL 查询。 据估算，该工具将 SQL 查询的编写时间从 **约 10 分钟缩短到了 3 分钟**。 #### **开发历程** QueryGPT 最初是在 **2023 年 5 月 Uber 的生成式 AI 黑客马拉松** 上提出的，并经过 **20 多次迭代** 才发展到当前的架构。 最初的版本使用 **RAG（检索增强生成）** 系统来获取相关的 SQL 示例和表结构信息。其流程如下： 1. **用户输入自然语言查询** 2. **系统向量化输入**，然后进行相似性搜索以检索相关的 SQL 代码片段和表结构 3. **LLM 结合这些信息，生成 SQL 查询** #### **开发背景** Uber 的数据平台每月要处理 **约 120 万个交互式查询**，其中 **运营部门贡献了约 36%**。 通过自动化 SQL 查询的生成过程，**QueryGPT 使非 SQL 专家也能高效访问和操作数据**，极大地优化了工作流。 #### **总结** QueryGPT 代表了 Uber 在数据可访问性上的一次重大突破。它能将 **自然语言输入** 转换为 **可执行 SQL 查询**，从而提升整体效率和生产力。 ### Text to SPL [日志易 Text to SPL 探索](https://mp.weixin.qq.com/s/maEWbNBUhNaO0_WwfmSEPw) ![](images/ali-system-spl.png) ```jflex | ... | ... ``` [SLS 查询新范式：使用 SPL 对日志进行交互式探索](https://www.cnblogs.com/alisystemsoftware/p/18151174) > SPL 即 SLS Processing Language，是 SLS 对日志查询、流式消费、数据加工、Logtail 采集、以及数据 Ingestion > 等需要数据处理的场景，提供的统一的数据处理语法，这种统一性使得 SPL 可以在整个日志处理的生命周期内，实现 "Write Once，Run > Anywhere" 的效果。 ![](images/spl-arch.png) `` 是 SPL 指令，支持正则取值、字段分裂、字段投影、数值计算等多种操作，具体参考 SPL 指令介绍。 示例： ``` Status:200 | extend urlParam=split_part(Uri, '/', 3) Status:200 | extend timeRange = cast(BeginTime as bigint) - cast(EndTime as bigint ``` 示例 2： ``` Status:200 | where UserAgent like '%Chrome%' | extend timeRange = cast(BeginTime as bigint) - cast(EndTime as bigint) | where timeRange > 86400 ``` ================================================ FILE: src/ai4se-tabnine-devops-driven.md ================================================ # AI 辅助软件工程案例分析：Tabnine DevOps 驱动的 AI4SE 本节将探讨 Tabnine 如何巧妙地将生成式 AI 融入 SDLC，通过优化各个开发环节，从而提升开发团队的生产效率及其协作水平。 PS：尽管 Tabnine 的一些观点和产品示例是虚构的，但是他们的技术博客和产品展示给我们提供了一些有趣的想法，可以帮助我们更好地理解 AI4SE 的未来。 ## AI 与 SDLC 的深度融合 ![CI to AI](images/tabnine-ci-to-ai.png) - **效率和生产力:**。AI 显著减少了开发人员的任务时间，例如，代码重构时间减少 30%，代码生成时间减少 45%，文档编写时间减少 50%；它将高复杂度任务的完成率提高了 30%。 - **开发人员满意度:**。AI 工具提高了开发人员专注于有意义工作的能力，使满意度从45%提高到88%。 - **采用和集成:**。AI 无缝集成到主要 IDE 中，并支持多种编程语言和框架；可定制模型可以在特定数据上进行训练，以提高输出质量。 ### 1. 规划阶段的AI助力 在SDLC的规划阶段，开发人员通常需要花费大量时间查找和理解项目的现有代码。Tabnine 通过分析本地和全球代码库，提供即时的代码建议和解决方案， 使开发人员能够迅速找到所需的信息，从而减少无效的时间消耗，并帮助团队更好地制定开发计划。 ### 2. 创建阶段的代码生成 Tabnine的AI工具在代码创建过程中尤为强大。通过智能代码补全和生成功能，开发人员可以依赖Tabnine在低复杂度任务（如创建简单类）和高复杂度任务（如解析数据结构）中提供的支持。 这样的自动化不仅加快了开发速度，还减少了错误的发生概率。 ### 3. 测试阶段的自动化生成 AI在测试阶段的应用也极大地提升了效率。Tabnine能够自动生成单元测试，确保代码的高覆盖率，同时减少了开发人员手动编写测试用例的负担。 它还支持生成符合现有测试框架的断言，从而简化了测试过程。 ### 4. 修复错误与实时反馈 在错误修复阶段，Tabnine的AI提供实时的错误检测和修复建议，帮助开发人员迅速定位并解决问题。这种基于上下文的个性化建议， 可以显著减少调试时间，并提高代码的可靠性。 ### 5. 文档编写的自动化 文档编写是开发过程中常被忽视但至关重要的部分。Tabnine通过生成全面的代码文档，包括API指南、注释和内联文档，不仅提高了代码的可读性， 还帮助新开发人员更快地理解和维护代码。 ### 6. 代码维护的智能支持 在维护阶段，Tabnine通过提供代码的全局视图和上下文相关的建议，简化了代码的重构和优化。它能够帮助团队成员理解复杂的代码结构， 从而加速新成员的入职流程，并确保代码的长期可维护性。 ## Tabnine + SDLC 智能体 ![Tabnine Connection](images/tabnine-connection.svg) ### Onboarding Agent：加速新成员入职 [Onboarding Agent](https://www.tabnine.com/blog/introducing-tabnines-onboarding-agent-revolutionizing-developer-onboarding/) 是 Tabnine 推出的一项新功能， 专为开发人员在新项目中快速适应而设计。它通过提供项目结构、可运行脚本和依赖关系的简明总结，极大地简化了新开发人员的入职过程。 ![Onboarding Agent](images/onboarding.gif) Onboarding Agent不仅提升了团队的整体效率，还增强了开发人员的自主性，使他们能够更快地融入团队并开始有效工作。 1. **集成与可用性**： - 作为 Tabnine Chat 的内置命令，无缝集成。 - 对所有 Tabnine SaaS 用户和支持 Tabnine AI 的 IDE 兼容。 2. **操作简便**： - 可通过简单命令 (/onboarding) 或在新对话开始时自动触发。 - 提供项目结构、可运行脚本、依赖关系等的简明总结。 3. **互动和个性化**： - 不仅提供信息摘要，还作为一个导游，为用户提供定制的后续问题建议。 - 让开发人员可以根据自己的需要深入探索项目的特定部分。 对开发人员的益处： - **提高效率**：加快了新项目的熟悉过程，节省时间。 - **增强自主性**：使开发人员能够独立地了解和操作项目。 - **快速上手**：帮助他们更快地成为项目团队的有效成员。 对组织的益处： - **降低成本**：减少了资深团队成员辅助新人的时间成本。 - **优化工作流程**：简化了新成员加入或项目切换带来的工作中断。 - **知识分享**：促进组织内部的效率和知识共享文化。 Onboarding Agent 代表了开发工具领域的重要进展，旨在提升开发效率，加速项目启动时间，为组织带来更高的创新能力和竞争力。 ### Jira-to-Code：从需求到代码的智能转化 [Tabnine 与 Atlassian Jira 的集成](https://www.tabnine.com/blog/unveiling-tabnines-vision-for-the-future-the-atlassian-jira-to-code-ai-agent/) 展示了AI在将需求直接转化为代码方面的巨大潜力。通过Tabnine的Jira-to-code智能体，开发团队可以从Jira任务中自动生成功能完备的应用程序。尽管这一功能仍处于早期阶段，但它展示了AI如何通过简洁、个性化和反思性的方法，大幅度提升软件开发的效率。 最近公布的智能体，如SWE-Agent、gpt-engineer、Devika和Devin展示了巨大的潜力，并展示了AI智能体在软件开发生命周期中不断增加的潜力。 这些智能体配备了类似于开发人员可用工具的广泛工具包，以完成他们的任务。为了在企业环境中使这些智能体成为高效的现实，我们认为智能体应具备以下特性： - **简洁性**：与智能体的交流必须简洁明了。这不仅适用于向智能体提供输入，也适用于消耗其输出。软件开发的重要部分是从通常不充分定义的定义中发现所需的行为。智能体的效果很大程度上取决于能够快速迭代任务，并以紧凑的输入和输出进行交互。 - **个性化和增量化**：智能体必须意识到当前代码库、组织的最佳实践、文档和它所协助的人类开发者的风格和偏好。一个生成与当前代码库不一致代码的智能体，可能会限制其适用性，而不是重新利用组件。 - **可靠性**：人类必须信任智能体提供的输出。审查智能体生成的成千上万行代码以发现微妙的错误，可能会限制委托任务给智能体的价值。 - **探索性**：一个有效的智能体必须能够在需要时向人类探询额外的上下文和指令。人 <-> AI 对话的效果对智能体在实际生活中的成功至关重要。 - **自我意识（反思性）**：智能体必须能够意识到当其完成一个任务并得到不满意的结果时。一个有效的智能体应该能够向人类反馈如何完成任务，以指导其改进过程。 Tabnine实现AI智能体的方法 - **自然语言交互**：通过Tabnine Chat提供企业级、以代码为中心的聊天应用程序，允许开发者使用自然语言与AI模型交互，关联Jira工单并手动修改生成的代码。 - **上下文感知**：向智能体提供Tabnine关于项目的丰富信息，并支持IDE操作工具，检索信息来自向量内存和语义内存。 - **沙盒执行环境**：允许智能体执行生成的代码并检查其符合测试用例，未来计划通过集成额外工具改进。 - **提出澄清问题和后续问题**：智能体会在任务执行中主动向人类开发者提出澄清和后续问题，以应对任务的现实复杂性。 - **智能体反思机制**：智能体会反思其工作，并可能对计划进行内部调整或提出更多问题，保持“人在循环”的反馈机制。 ![Tabnine Context aware](images/tabnine-context-aware.svg) ### 与 Bitbucket 的全面集成 [Tabnine与Atlassian Bitbucket](https://www.tabnine.com/blog/tabnine-atlassian-ai-enabled-software-development-built-around-you/) 的集成进一步展示了AI在增强开发运维（DevOps）流程中的作用。通过与Bitbucket的深度连接，Tabnine能够为整个团队提供个性化的代码建议，并帮助团队共享代码上下文，提升协作效率。此外，Tabnine还支持对AI模型进行定制，以优化在特定代码库中的表现，为开发团队提供更精准的支持。 从 DevOps 和 AI 的角度来看， Tabnine 与 Atlassian 产品的集成展示了如何利用人工智能增强开发运维（DevOps）流程的效率和质量。以下是一些关键点的总结： 1. **全面的代码感知和个性化建议**：通过与 Bitbucket 和其他 Git 仓库的集成，能够在开发者 IDE 中提供高度个性化的代码完成建议。这不仅仅是静态的代码补全，还包括变量类型、注释、已打开文件和项目的上下文信息，从而显著提升了开发者的工作效率和代码质量。 2. **全局代码感知和团队协作**：通过与 Bitbucket 的全局连接， Tabnine 扩展了其能力，使得整个工程团队能够共享和利用更丰富的代码上下文。这对于大型企业和跨部门协作的团队尤为重要，可以加强对代码库的理解和重用，从而提升整体的开发效率和协作水平。 3. **AI 模型定制和性能优化**： Tabnine 通过定制 AI 模型，利用 Bitbucket 中存储的代码库进行优化，特别是针对不常见的编程语言或框架。这种个性化和优化能力提高了 AI 在软件开发过程中的表现，为开发团队提供更精准和高质量的代码生成和支持。 4. **提升团队生产力的工具和平台支持**： Atlassian 和 Tabnine 的集成不仅仅是工具级别的整合，更是为工程团队提供了全方位的工具和平台支持，帮助团队在 DevOps 实践中更有效地运用人工智能技术，从而加速交付周期、提高软件质量和团队的整体生产力。 综上所述， Tabnine 与 Atlassian 产品的结合展示了如何从 DevOps 和人工智能的融合中获得多方面的利益，为软件开发团队提供了强大的工具和平台支持，推动团队在敏捷开发和持续交付中取得更大的成功。 ## 其它 ### 软件开发中AI的未来： - AI将全面了解组织的整个工作区，导致全面的测试覆盖率和文档编写。 - 它将显著减少代码维护所花的时间，使团队能够专注于创新。 - 像Tabnine这样的AI工具提供安全、可定制且上下文相关的解决方案，满足企业需求，确保知识产权的控制和法律标准的合规。 通过解决这些关键领域，AI帮助软件开发团队克服了高工作量、复杂需求、技术债务和人才保留等挑战，最终提高了SDLC的整体效率和效果。 ### 相关文章 - [From CI to AI: The AI layer in your organization](https://www.tabnine.com/blog/from-ci-to-ai-the-ai-layer-in-your-organization/) - [How AI code assistants speed up and simplify the SDLC](https://www.tabnine.com/blog/how-ai-code-assistants-speed-up-and-simplify-the-sdlc/) ================================================ FILE: src/ai4se.md ================================================ # AI 辅助软件工程：AI4SE 的 2024 趋势 > AI4SE（Artificial Intelligence for Software Engineering）是指人工智能技术应用于软件工程领域，旨在通过利 用AI 算法和工具来改进软件开发、 > 维护、测试和管理等各个环节的效率和效果。AI4SE的核心目标是通过自动化和智能化技术，降低软件开发的复杂性，提高软件的质量，并加速软件工程过程。 从 2024 年的视角回顾，与 2023 年相比，AI 在软件工程中的应用已经变得更加广泛和深入。这一趋势体现在AI编程工具的进化上，主要体现在以下几个方面： 1. 全面探索：从辅助开发人员到全生命周期 2. 演进路径：个体、团队、组织 3. 形态变化：从本地 AI IDE 到领域特定的智能代码生成 站在全球来看，在不同的国家、区域人们的关注点是不一样的，比如在中国，人们更关注于如何提高软件工程师的工作效率，而在其它一些区域，人们更关注于如何 提高软件工程的质量、如何辅助进行遗留系统的迁移。 除了各自所处的数字化阶段、水平不同，还存在一些技术人才数量、质量、分布等方面的差异。 ## 全面探索：从辅助开发人员到全生命周期 AI 技术已经从简单的辅助开发人员发展到涵盖软件开发的整个生命周期。在这一过程中，AI 工具的应用范围不断扩展，从需求分析到运维管理，每个阶段都得到了显著提升。 ### 单工具 Copilot 下图是，Thoughtworks 在 2023 年初对 AI 辅助软件工程的流程分析，即在软件开发的不同阶段，AI 可以提供哪些辅助功能： ![AI DevOps 流程](images/aise-devops-processes.png) 从 2022 年 GitHub Copilot 的发布，我们可以看到越来越多的 AI 工具开始涉足到软件开发的不同阶段。 - 需求阶段的 Jira/[Atlassian Intelligence](https://www.atlassian.com/platform/artificial-intelligence) - 原型设计的 [Vercel V0](https://v0.dev/) - 编码阶段的 GitHub Copilot - 运维阶段的 [Dynatrace Davis AI](https://www.dynatrace.com/platform/artificial-intelligence/) - …… 就 2023 年的结论而言，基于人工智能的工具与基础大语言模型可以增强软件开发在设计、 需求、测试、发布和运维等各个环节中的能力，提高质量和效率。 但是，这些工具往往是破碎、割裂的，还可能并不适合我们现有的研发流程。 ### AI 原生的研发工具 在市场上，我们也可以看到市面上的主流研发工具，如 JetBrains、GitHub（网站）等，都在逐渐加入 AI 功能，使得 AI 功能逐渐融入到我们的日常工作中。 ![AI Native 工具](images/ai-native-rd-tool.png) 在 IntelliJ IDEA 中，我们可以看到 AI 功能的加入，如： - 原生的向量化模型 - 基于语义化搜索（SearchEverywhere） - 结合补全统计的机器学习补全插件：Machine Learning Code Completion - 适用于单个代码行的 Full Line Code Completion - 等等 而除了 GitHub Copilot 工具本身，其也开放了其插件能力，使得我们可以定义自己的 AI 智能体，以适应我们自己的工作流程：[Chat extensions](https://code.visualstudio.com/api/extension-guides/chat) ### 多阶段协同 在 2024 年，我们可以更多的变化，诸如： - 在智能运维领域，AI 可以结合判别性 AI 分析日志，生成式 AI 分析原因，再结合智能体跟据运行错误，自动修代码复问题等 - 在测试领域，AI 除了辅助进行测试用例的生成，还可以生成对应的单元测试代码，甚至是自动化测试代码。 - 在 UI 设计领域，AI 可以直接生成对应的代码，基于提示词来修改 UI，所生成的是最终的 UI 代码，而不是设计稿。 - …… 如下是 Dynatrace 的 Davis AI 示例： ![hypermodal AI](images/davis-chart.png) Dynatrace 的 Hypermodal AI（超模态人工智能），是一种将多种类型的人工智能整合在一起，以增强可观察性和安全解决方案的高级方法。 这个概念结合了三种不同的AI模式： 1. **预测AI**：使用历史数据和观察到的模式来预测未来的行为和需求。这对于在问题发生之前预见并防止潜在问题至关重要。 2. **因果AI**：专注于实时分析富有上下文的数据，以确定问题的根本原因并自动化风险缓解。这种类型的AI通过理解系统内的依赖关系和交互，提供精确的答案。 3. **生成AI**：利用高级算法来创建针对特定问题的建议和解决方案。通过提供上下文相关的建议和使用自然语言处理自动化任务，这种AI增强了用户互动。 通过融合这些AI功能，超模态AI为管理复杂的软件环境提供了更全面和有效的解决方案。Dynatrace 的 Davis AI 平台通过整合预测 AI、因果 AI 和生成 AI， 提供实时洞察、自动化和增强的数字服务安全性。 诸如此类的变化，使得 AI 所能辅助的范围更加广泛，从而使得 AI 在软件工程中的应用更加全面。 ## 演进路径：个体、团队、组织 从企业采用 AI 的路径来看，我们会发现：越来越多的组织开始探索在组织层面使用 AI 辅助整体软件研发。因而，AI 辅助研发组织的技术蓝图便也逐渐清晰起来： ![AI for Org](images/ai-for-org.png) 从形态上可以分为：带扩展能力的 IDE 插件、团队 AI 助手、 结合 AI 的内部 IM，以及作为基础能力的 Chatbot。 ### 个体辅助 IDE 插件示例：AutoDev AI 编程工具应该怎么设计才能提效？在当前来说，国内的环境下，由于我们的目标是**实现可见的效率提升**，即要通过可度量的指标。因而，可以看到一些明显 的变化： 1. 代码补全与生成是最容易度量的指标，并且市面上也以此类为主。 2. 在不同环节，从时间角度来计算，如代码审查、代码测试等。 3. 结合代码的问答，以减少工具切换、复制粘贴，提高效率。 如下是我们开源的 IDE 插件 AutoDev 的能力全景图： ![AutoDev 能力全景](images/autodev-landscape.png) 由于过去的 AI 编程工具主要面向的是个体开发者，而随着探索进入一些深入区，以及实践的不断推进。所以，在结合组织能力的情况下，我们可以看到： - 多样的 AI 工具正在融入自己的开发流程中 - AI 工具开始融入内部的一系列规范 - 不断结合内部知识库，提升内容生成的质量 - 开始构建自己的场景化能力 故而，我们将其总结为，从个体到团队，再到组织，并开始思考如何扩大 AI 的应用范围。 ### 团队 AI 助手示例：Haiven 在设计团队 AI 助手时，我们需要考虑到团队的拓扑结构，以及团队的工作流程。如下图所示： ![团队拓扑](images/team-topologies.png) 在一个组织中，必然会有大量的不同类型的团队，每个团队受限于业务盈利模式等因素，其采用的技术、工作流程等都会有所不同。诸如于，核心的业务部门可以 享受自己特有的开发流程，而其它非核心部门则会采用一些标准化的流程。 考虑到盈利水平高的部门，通常是大型团队，他们不仅可能有自己的 AI IDE 插件，还会有自己的 AI 团队。因此，我们也建议设计一个可以让不同团队共享知识的 AI 团队助手。 诸如于 Haiven™ 团队助手： > [Haiven™ 团队助手](https://github.com/tw-haiven/haiven) 是由 Thoughtworks 开发的一款 AI 驱动工具，旨在增强软件开发流程。它与现有的 > AI 编码助手集成，并提供可插拔的知识包，帮助团队完成开发任务、加速反馈循环，并推动创新。Haiven 支持多种云和身份提供商，便于采用并集成到现有工作流程中。 > 它支持研究、用户旅程分析、 架构开发和团队知识编码，从而提升生产力、质量和团队能力，同时保持对 AI 环境的控制。 - **提高软件开发的生产力和质量**。可复用提示词（prompt）可以将最佳实践和即时知识融入团队的工作流程，以减少浪费，提升开发者满意度，并保持软件质量始终如一。 - **动态增强团队成员能力**。Haiven 增强了团队的自然人类创造力，使他们能够轻松研究用户需求，探索创新功能并交付卓越的用户体验。 - **易于采用**。支持多云和身份提供商，以及可根据团队工作流程定制的可插拔知识包，Haiven 极易被采用和集成。 - **理解今天的 AI 的潜力**。AI 市场是动态且迅速发展的，许多工具并未专门针对软件开发任务设计，或者只关注有限的功能范围。Haiven 提供了一个简单的沙盒，用于今日试验新功能。 通过基础的 AI 赋能，让不同团队在有能力的情况下，可以根据自己的需求，定制自己的 AI 助手。 ### 组织级 IM/Chatbot 示例 回到整体组织层面，我们也会看到内部的 IM 工具也在融合 AI 功能，以提升协作体验。诸如于： - 寻找负责人/专家：通过 AI 助手，可以快速找到组织内的专家，以解决问题。 - 运维 Chatbot，辅助分析部署失败问题，可以自动化运维任务，如自动化部署、自动化监控等。 - CI/CD 问题分析：通过 AI 助手，在尝试修复问题时，还可以告知问题的可能根因。 - AI 会议创建与管理。通过 AI 助手，可以自动创建会议，自动邀请参会人员，自动记录会议内容，自动提醒会议时间等。 如下是 Teams Copilot 的示例： ![](images/teams-copilot.png) 在另外一方面，我们也会有大量的其它 Chatbot 在不同的研发团队中使用，诸如于辅助平台的使用、文档查找等等。 ## 形态变化：从本地 AI IDE 到领域特定的智能代码生成 与通用性的 AI 辅助相比，领域特定的 AI 辅助效果更好，因为它更了解领域的特点，更容易生成符合领域规范的代码。从智能代码生成的角度来看，由于过去包含 大量的语料知识，生成的代码质量更高，更符合领域规范。 ### IDE 即 AI 辅助研发中心 在前面，我们已经看到了 AI 辅助研发中心的概念，即在一个组织中，AI 辅助研发中心可以为不同团队提供 AI 能力，以提升整体的研发效率。 还需要注意的是，AI 在快速生成大量代码的同时，也会带来一些问题，如代码质量、安全性等。我们需要考虑如何在 AI 生成代码的同时，保证代码的质量。如下图 所示： ![](images/ai-coding-with-sonarlint.png) 我们需要考虑[构建类似于 SonarLint 的体系化质量检查](https://www.sonarsource.com/learn/ai-assisted-software-development/) 工具，以保证 AI 生成的代码质量。 ### AI 增强的低代码平台 诸如低代码应用程序平台 Appian 的[分析文章](https://appian.com/blog/acp/process-automation/generative-ai-low-code-things-to-know) ，生成式 AI 与低代码平台结合，可以在多个方面实现增强的生产力和创新： 1. **文本生成与聊天机器人：** 结合生成式 AI 和低代码平台，能够快速部署聊天机器人，处理基本的客服请求或生成待人审阅的电子邮件草稿，从而简化沟通流程。 2. **从 PDF 构建界面：** 生成式 AI 能够解析 PDF 设计并将其转换为功能性界面或表单。结合低代码平台，确保设计到代码的准确转换，无需额外校对。 3. **工作流程自动生成：** 通过生成式 AI 增强的低代码平台，可以快速生成复杂的工作流程，包括视觉图表和可执行代码。这对于例如账单管理等任务至关重要，用户反馈后能快速进行迭代改进。 4. **自助式分析：** 利用自然语言处理的 AI 驱动平台，团队能够快速从数据源生成报告和洞察。AI 与低代码的结合，使得能够灵活调整流程和操作，提升业务效率和决策能力。 除了上述的经典场景之后，我们也可以看到多模态 AI 代码的生成，诸如于 Google 的 [ScreenAI](https://research.google/blog/screenai-a-visual-language-model-for-ui-and-visually-situated-language-understanding/)。 ![](images/screen-ai-schema.png) 它可以将图像和文本结合起来，生成对应的 DSL，进而转换成不同的代码。 ```markdown You only speak JSON. Do not write text that isn’t JSON. You are given the following mobile screenshot, described in words. Can you generate 5 questions regarding the content of the screenshot as well as the corresponding short answers to them? The answer should be as short as possible, containing only the necessary information. Your answer should be structured as follows: questions: [ {{question: the question, answer: the answer }}, ... ] {THE SCREEN SCHEMA} ``` 当然了，为构建这样的语料，你还需要生成大量的页面与低代码数据。 ### 从云 IDE 到智能云开发环境 在云 ☁️ 时代，大型组织构建了大量的云 IDE 和云基础设施，以尝试卖出更多的云服务以及解决最后一公里的部署问题。尽管，受限于云 IDE 能力、网络与计算能力， 云 IDE采用并不高，但是随着 AI 的发展，我们可以看到更多的智能云开发环境的出现。 虽然..但是..，我们非常看好诸如 v0.dev 这一类针对于领域特定的开发工具。 ![v0.dev](images/v0-dev-sample.png) 它可以： - 高效 UI 生成：通过输入提示词快速创建前端组件和页面。 - 一键定制化组件：少量的提示词即可创建优雅复杂的组件，一键导出并应用于项目。 - 快速原型设计：提供即用生产代码，适用于新旧项目，项目较大时需整理代码结构。 - 图生成代码：通过图形化界面生成代码，适用于新手，不熟悉代码的人员。 它可以快速帮助我们构建出一个原型，然后再进行。再结合其它 AI 工具，如代码审查、代码测试等，可以大大提高我们的开发效率。 还有诸如 Google [Project IDX](https://developers.google.com/idx) 这一类 AI 辅助型工作区。IDX 支持众多框架、语言和服务， 还与 Google 产品集成，可简化您的开发工作流程，让您可以快速、轻松、高效地跨平台构建和发布应用。 ![IDX Demo](images/idx-demo.png) 尽管 IDX 还非常早期，但是我们可以看到，未来的云 IDE 将会更加智能化，更加适应我们的工作流程。 在国内，我们也可以看到 [Babel Cloud](https://babelcloud.ai/)、MarsCode 等一系列云 IDE 工具，也在不断的发展中。 ## 其它 AI 在软件工程中的应用已经从辅助开发人员扩展到整个开发生命周期，逐步演进为团队和组织层面的协作工具，并在工具形态上实现了从本地 AI IDE 到领域特定智能代码生成的转变。这些变化不仅提高了开发效率和质量，还推动了整个软件工程领域的发展。 1. **全面探索**：AI 从辅助开发人员扩展到覆盖软件开发的整个生命周期，从需求分析到运维管理，每个阶段都显著提升了效率和质量。 2. **演进路径**：AI 工具从个体使用扩展到团队和组织层面。个体使用的 AI 工具如 AutoDev，团队助手如 Haiven，以及组织层面的 AI 集成到内部 IM 和 Chatbot 系统中，全面增强了协作和效率。 3. **形态变化**：从本地 AI IDE 发展到领域特定的智能代码生成工具。智能云开发环境如 Google 的 Project IDX 等工具，使得未来的开发流程更加智能化和高效。 这些变化不仅提高了开发效率和质量，还推动了整个软件工程领域的发展。 相关材料： - 材料见：[大模型时代， AI 辅助编程工具的技术演进](https://github.com/unit-mesh/conf/blob/master/%E5%A4%A7%E6%A8%A1%E5%9E%8B%E6%97%B6%E4%BB%A3%EF%BC%8C%20AI%20%E8%BE%85%E5%8A%A9%E7%BC%96%E7%A8%8B%E5%B7%A5%E5%85%B7%E7%9A%84%E6%8A%80%E6%9C%AF%E6%BC%94%E8%BF%9B.pdf) - B 站视频：[大模型时代，AI辅助工具的技术演进-黄峰达](https://www.bilibili.com/video/BV1HJ4m1p7Dp/) ================================================ FILE: src/aise-api-test.md ================================================ # AI 辅助软件工程：AI 生成 API 测试 ## 示例 ### 示例：HTTPie AI [HTTPie AI 助手](https://httpie.io/blog/ai) 利用先进的自然语言处理技术，使用户能够通过简单的自然语言描述来生成和管理 API 请求，而不需要手动编写请求代码。HTTPie AI 可以理解用户的意图，将其转换为相应的 HTTP 请求，从而简化与 API 的交互过程，提高开发者的工作效率。 ![](images/httpie-ai.webp) ================================================ FILE: src/aise-code-check.md ================================================ # AI 辅助软件工程：AI 辅助代码质量检查 对开发人员的提效，好的情况会提速50%，差的可能还拖慢进度（如针对初级开发者）。这取决于编程方式、开发任务的类型、使用的编程语言， 以及在使用聊天接口时如何制定恰当的提示指令。警惕AI生成代码可能带来的代码质量下滑([GitClear研究](https://www.gitclear.com/coding_on_copilot_data_shows_ais_downward_pressure_on_code_quality)) ，监控代码质量变化并做好保障措施。 ## 基础：理解 SAST 主要用途： - 自动化源代码扫描，以预防漏洞并在开发管道早期捕获它们。 - 扩展漏洞检测。通过变体分析技术，SAST工具可以在代码库的不同部分检测到已知漏洞的变体，从而发现新的漏洞。 - 协助手动代码审查。在CodeQL中，GitHub的SAST工具，你的代码被视为数据进行分析。 ![SAST Tool](images/sast-tool-diagram.png) 阅读：[The architecture of SAST tools: An explainer for developers](https://github.blog/2024-02-12-the-architecture-of-sast-tools-an-explainer-for-developers/) ### 步骤示例 基于提供的详细描述，以下是高级 SAST（静态应用安全测试）工具（如 CodeQL）在扫描 SQL 应用程序中查找漏洞（特别是 SQL 注入攻击）时采取的五个主要步骤： 1. **对源代码进行词法分析：**。SAST 工具首先执行词法分析，将源代码分解为标记（tokens）。标记代表编程语言语法的标准化元素，这有助于后续分析。这一步骤使工具能够专注于有意义的代码组成部分，而忽略无关的字符。 2. **将源代码抽象为AST（抽象语法树）：** 。在完成词法分析后，工具从源代码构建抽象语法树（AST）。AST 将代码组织成层次结构，展示代码各部分之间的关系，比如哪些语句属于哪些函数。这种抽象有助于理解代码的结构和含义。 3. **进行语义分析：**。借助 AST，进行语义分析以解释代码的预期行为和逻辑。语义分析使得SAST工具能够专注于代码的语义，而不是注释或格式。这一步骤对于识别由于不正确或不安全的编码实践导致的漏洞至关重要。 4. **进行污点分析：** 。污点分析用于跟踪用户控制的输入数据在整个代码库中的流动路径。它识别输入数据的来源（数据进入系统的位置）、净化器（确保输入安全的函数）和污点（如果用未经净化的输入数据调用可能会存在漏洞的函数）。通过追踪输入数据从源头到污点的流动，工具评估是否应用了适当的验证和净化。如果未经净化的输入达到污点，工具会发出潜在的安全漏洞警报。 5. **生成安全警报：** 。基于语义分析和污点分析的结果，SAST 工具为在代码中检测到的潜在漏洞生成安全警报。这些警报优先考虑未经净化的输入数据可能导致安全问题的路径，例如SQL注入漏洞。警报为开发团队提供可操作的信息，使他们能够有效地优先处理和解决安全问题。 这些步骤说明了 SAST 工具（如 CodeQL）如何利用先进的分析技术，在开发生命周期早期检测到漏洞，从而增强代码安全性。 ## 业内案例：基于查询语言 ### GitHub CodeQL 文档：https://codeql.github.com/ ```codeql import TaintTracking::Global from PathNode source, PathNode sink where flowPath(source, sink) select sink.getNode().(UnsafeDeserializationSink).getMethodAccess(), source, sink, "Unsafe deserialization of $@.", source.getNode(), "user input" ``` [CodeQL 查询过程](https://www.microsoft.com/en-us/security/blog/2021/02/25/microsoft-open-sources-codeql-queries-used-to-hunt-for-solorigate-activity/) ![](images/codeql-pipeline.png) CodeQL 是一种强大的语义代码分析引擎，现在已经成为 GitHub 的一部分。它的处理流程主要分为两个阶段，特别适用于大规模源代码的分析： 1. **数据库构建阶段：** - CodeQL 在源代码编译成二进制文件时，构建一个数据库来捕获编译代码的语义模型。 - 对于解释性语言，由于没有编译器，CodeQL 会解析源代码并构建自己的抽象语法树模型。 2. **查询数据库：** - 构建好的数据库可以反复查询，使用 CodeQL 语言进行分析。这种语言专门设计用于从数据库中选择复杂的代码条件，能够详细分析代码模式和结构。 3. **语义分析：** - CodeQL 允许在集中的基础设施中进行语义分析，跨多个代码库进行查询。这种集中分析能力使得 Microsoft 能够同时在数千个代码库中进行查询。 - 语义分析涉及查找可能跨越不同代码部分（如程序集、库或模块）的模式，这些部分是基于构建的具体代码的。 相关文章： - [CodeQL zero to hero part 1: The fundamentals of static analysis for vulnerability research](https://github.blog/2023-03-31-codeql-zero-to-hero-part-1-the-fundamentals-of-static-analysis-for-vulnerability-research/) - [CodeQL zero to hero part 2: Getting started with CodeQL](https://github.blog/2023-06-15-codeql-zero-to-hero-part-2-getting-started-with-codeql/) - [CodeQL zero to hero part 3: Security research with CodeQL](https://github.blog/2024-04-29-codeql-zero-to-hero-part-3-security-research-with-codeql/) ### Synk QL https://docs.snyk.io/scan-using-snyk/snyk-code/snyk-code-custom-rules/create-query AST ```bnf ::= | ' ' ::= | | |