Tapd需求单自动创建分支拉流水线 Skill

一、技能概述与价值

1.1 技能定位

这是一个专为Q音iOS团队设计的自动化工具，旨在解决日常开发中的重复性工作：

• 痛点：每次处理新需求时，需要手动创建分支、配置流水线、添加权限
• 方案：通过自动化工具实现一键完成全流程
• 价值：单个需求节省15-20分钟，降低人工操作错误率

1.2 核心功能矩阵

1
2
3
4
5
6
7
8
9
10
11

┌─────────────┬─────────────────────────────┬─────────────────┐
│ 阶段         │ 功能模块                    │ 传统耗时        │
├─────────────┼─────────────────────────────┼─────────────────┤
│ 需求获取     │ TAPD自动登录与信息提取      │ 3-5分钟         │
├─────────────┼─────────────────────────────┼─────────────────┤
│ 代码管理     │ 工蜂分支自动创建            │ 2-3分钟         │
├─────────────┼─────────────────────────────┼─────────────────┤
│ 流水线配置   │ 蓝盾流水线创建与配置        │ 5-8分钟         │
├─────────────┼─────────────────────────────┼─────────────────┤
│ 权限管理     │ 自动添加相关人员权限        │ 2-3分钟         │
└─────────────┴─────────────────────────────┴─────────────────┘

转载 一文读懂 Skills｜从概念到实操的完整指南

原文地址

Agent 正在经历从“聊天机器人”到“得力干将”的进化，而 Skills 正是这场进化的关键催化剂。

你是否曾被 Agent 的“不听话”、“执行乱”和“工具荒”搞得焦头烂额？

本文将带你一文弄懂 Skills ——这个让 Agent 变得可靠、可控、可复用的“高级技能包”。

我们将从 Skills 是什么、如何工作，一路聊到怎样写好一个 Skills，并为你推荐实用的社区资源，带领大家在 TRAE 中实际使用 Skills 落地一个场景。

无论你是开发者还是普通用户，都能在这里找到让你的 Agent “开窍”的秘诀。

你是否也经历过或者正在经历这样的“ Agent 调教”崩溃时刻？

• 规则失效： 在 Agent.md 里写下千言万语，Agent 却视若无睹，完全“已读不回”。
• 执行失控： 精心打磨了无数 Prompt，Agent 执行起来依旧像无头苍蝇，混乱无序。
• 工具迷失： 明明集成了强大的 MCP 工具库，Agent 却两手一摊说“没工具”，让人摸不着头脑。

如果这些场景让你感同身受，别急着放弃。终结这场混乱的答案，可能就是 Skills。

[转载] 认知重建：Speckit用了三个月，我放弃了——走出工具很强但用不好的困境

原文地址

2025 年 AI 编程工具遍地开花，但一个尴尬的现实是：工具越来越强，预期越来越高，落地却越来越难——speckit 的规范流程在企业需求的”千层套路”、海量代码面前显得理想化，上下文窗口频繁爆满让复杂任务半途而废，每次做类似需求还是要花同样的时间因为知识全在人脑里。本文记录了我从踩坑规范驱动工具，到借鉴 Anthropic 多 Agent 协作架构、融合上下文工程与复合工程理念，最终实现边际成本递减、知识持续复利的完整历程。如果你也在”AI 工具明明很强但就是用不好”的困境中挣扎，或许能找到一些共鸣。附带还有新的工作流下人的工作模式转变思考～

起点：规范驱动开发的美好承诺

1.0 团队的 AI Coding 起点

先交代一下背景：我所在的是一个后端研发团队，日常工作以存量项目迭代为主，涉及多个微服务的协作开发。

2024 年中，团队开始尝试 AI 辅助编程。最初的体验是：

短上下文场景效果不错：

• 写一个独立函数、实现一个工具方法——AI 表现良好
• 简单的代码补全、格式化、注释生成——确实提效

但规模化复用始终没起来：

• 当时只有三种触发类型的 rules（早期 rules 时代）
• 虽然提出过”在基础 agent 之上封装 agent”的想法
• 但几个月过去，仍然没有太多人真正动起来

原因分析：

• 规范没有形成共识——每个人对”怎么用好 AI”理解不同
• 对 AI 工程化没有标准认识——不知道该往哪个方向努力
• 提示词复用习惯没建立——好的 prompt 停留在个人经验，没有沉淀

这个困境促使我开始探索外部方案：有没有已经成熟的”AI 编程工程化”方法论？有没有可以直接借鉴的最佳实践？

带着这些问题，我遇到了 speckit 和 openspec。

遇见 speckit：AI 编程的”正确打开方式”？

Title: 彻底爆了！一文吃透AIGC、Agent、MCP的概念和关系-腾讯云开发者社区-腾讯云

原文地址

导语: 近年来，人工智能 领域涌现出许多新概念和新技术，其中AIGC、MCP和 Agent 成为了业界和学术界的热门话题。本文将深入浅出地介绍这三个概念，帮助读者全面理解它们的内涵、区别与联系，以及在实际应用中的价值。

AIGC

AIGC，全称为 AI Generated Content，意为“人工智能生成内容”。它指的是利用人工智能技术（尤其是大模型，如GPT、Stable Diffusion 等）自动生成文本、图片、音频、视频等多种内容的过程。2022 年 11 月 30 日，OpenAI 的 ChatGPT 正式上线（基于 GPT-3.5），引爆了 AIGC 热潮。

原文地址

AI coding 智能体设计

理解 AI coding 智能体的设计，可以帮助开发者更好地使用 AI coding 工具，实现开发提效。

了解用户提示词预处理，帮助我们写出高效的用户提示词。例如：为什么在提示词中使用 @字符引入文件、目录作为上下文，可以减少会话轮次？如何自定义命令？

• 了解智能体如何处理 MCP 扩展，如何解析 MCP 的 prompt 和 tool 能力，从而更好的进行 MCP 设计，为 AI coding 智能体提供子命令扩展和工具集扩展。
• 了解 SubAgent 的实现，理解上下文隔离的意义，基于高内聚、低耦合原则进行智能体的模块化设计，降低系统复杂度。
• 了解 MCP 工具调用的局限性，从而理解 Claude Code 推出 Skills、Code Execution with MCP 的动机和原理。
• 为什么规约驱动开发（spec-driven development）成为 AI coding 的最佳实践？通过对开源项目 OpenSpec 的解读，了解规约驱动开发背后的奥秘和改进点。
  本文从分析 Gemini-CLI 源代码开始，解读 AI coding 工具的智能体设计。Claude Code 本身不开源，但是实现原理大同小异。

在分析 Gemini-CLI 过程中，特别感谢 Qwen Code 团队，他们的开源项目中的 openaiContentGenerator包提供了OpenAI API的兼容层，使用这个模块可以很容易将 Gemini-CLI 内置的谷歌认证和外部模型切换为公司内部模型。

Gemini-CLI 的用户提示词预处理

在 Gemini-CLI 中输入提示词，首先对输入的内容进行预处理。

• 如果提示词的第一个字符是斜线（/），将提示词视为命令，执行特定操作，或者替换为预置提示词和大模型交互。
• 如果提示词中包含 @字符+路径，检查 @字符后的路径是否存在，读取文件作为上下文，再发送给大模型。可减少不必要的模型会话。

内置命令

Gemini-CLI 的内置命令在 packages/cli/src/ui/commands/目录下定义。

• 例如 clear 命令在文件 packages/cli/src/ui/commands/clearCommand.ts 中定义。

• 内置命令可以执行特定操作。例如：/clear 命令用于重置对话、清空上下文。

内置命令可以使用预置用户提示词调用大模型完成相关任务。例如：/init 命令使用大模型分析工程代码创建 GEMINI.md 文件。

内置命令列表参见：docs/cli/commands.md。

原文地址

话题内容：

• CLI的产品美学： 时代在倒退么？
• CLI的技术原理：Single Agent vs Multi Agent
• CLI的使用场景：如何用好CLI写代码？

话题背景：随着LLM的能力提升，从早些AI产品能快速帮助用户制作prototype，到现在当前市面上不断涌现出新的AI Coding工具，这些AI Coding背后的工具原理是什么？我们在选择这些AI Coding工具的时候，需要关注哪些信息，了解背后的原理，才能更好地使用这些工具。

Q：回想一下，你接触过哪些AI Coding工具？当前使用过程中有哪些问题？

时代在倒退么？ CLI的产品美学

当我第一次接触到Claude code的时候，很惊讶发现他是一个命令行工具，他不是一个IDE，甚至都不是一个插件，当时在想，是时代在倒退么？为什么还会有AI产品是一个命令行工具，像是回到了linux时代。随着使用越来越深入，逐渐发现了他的魅力。

在人工智能编程工具的浪潮中，CLI工具的崛起并非偶然。它的成功不仅在于强大的代码生成能力，更深层次的原因在于其背后遵循了一套历久弥新的设计哲学——与经典的Unix哲学不谋而合。

原文地址

本文系统回顾了淘特导购团队在AI编码实践中的演进历程，从初期的代码智能补全到Agent Coding再到引入Rules约束，最终探索SDD（Specification Driven Development，规格驱动开发）——以自然语言规格（spec.md）为唯一真理源，驱动代码、测试、文档自动生成，实现设计先行、可测试性内建与文档永不过期。实践中发现SDD理念先进但落地门槛高、工具链不成熟、历史代码集成难，因此团队当前采用融合策略：以轻量级技术方案模板为输入 + Rules严格约束 + Agent Coding高效实现 + AI自动汇总架构文档，形成兼顾规范性、效率与可维护性的AI辅助编程最佳实践。

背景

业务背景

生成式AI技术的范式突破正驱动智能开发工具进入超线性演进阶段，主流代码生成工具的迭代周期已从季度级压缩至周级，智能体架构创新推动开发效能持续提升。

淘特导购系统承载着商品推荐、会场投放、活动营销等多样化的业务场景，技术团队面临着需求迭代频繁、代码腐化及团队协作度高的问题，如何提升开发效率、保证代码质量、降低维护成本成为我们面临的重要挑战。正是在这样的背景下，我们开始尝试将AI技术融入到日常开发流程中，探索从传统编码到AI辅助编程的转变之路。

AI编程工具的引入

2024年初，团队开始探索AI编程工具，希望通过AI提升开发效率和代码质量。最初接触的是Aone Copilot（阿里内部AI工具）的代码智能补全功能，后来逐步尝试Agentic Coding、Rules约束、SDD（Specification Driven Development）等多种AI编程模式。本文将详细记录我们的探索历程、实践经验以及对AI编程未来的思考。

Kuikly 开发框架笔记

Kuikly（Kotlin UI Kit，发音同quickly），是使用Kotlin开发了声明式UI框架，映射到系统原生控件做渲染，最终用KMM（Kotlin Multiplatform Mobile）实现跨端。
Kuikly是一个开发语言高度同源的跨端框架，从业务代码、UI框架、布局层以及渲染层全部使用Kotlin语言（iOS渲染层是OC），这样不仅减少跨语言通信的性能成本，而且开发体验上更纯粹和高效。编译产物上，Android端采用原生的AAR方式，而iOS端通过KMM编译生成.framework，这样就不仅保证了原生开发体验，也保证了原生性能。如果希望实现动态化，Android端可以通过KMM编译成SO，iOS端可以编译成JS（KMM已经可以编译成Wasm，未来有稳定版本后就可以正式使用）。Kuikly具有优异的原生开发体验，相比于Hippy，更符合终端开发习惯。

Vibe Coding 在代码生成与协作中的实践与思考 - 向邦宇

自我介绍：

• 多年从事研发者工具开发，包括内部 AI Coding 工具和 Web IDE 工具
• 从 2023 年开始，从内部 Copilot 转型到 AI Agent 方向
• 作为产品提供方，接触了大量内部用户，观察他们如何使用工具以及遇到的问题

演讲选题思考：

• Vibe Coding 概念出现几个月，但并非确定性的东西
• 不同人对 Vibe Coding 理解不同，使用的工具也不同
• 从两个视角分享：用户使用场景和问题、产品提供方的思考和解决方案

演讲结构：

1. 简单介绍业界和内部有哪些 Vibe Coding 工具在使用
2. 用户在使用 Vibe Coding 工具过程中遇到的问题
3. 作为 Vibe Coding 工具核心主导者的思考
4. 国产模型适配过程中遇到的问题和解决方案

Vibe Coding 产品形态

当前工具分类的模糊性：

• 大家对 Vibe Coding 工具的理解和分类不够清晰
• 每个工具都有人在用，但缺乏明确的定位