現在我們的 Chat channel 裡面，住著幾個AI agent，這些AI agent由G哥領軍
大家每天都直接跟 G哥 工作：
「G哥，幫我查 xxxx 現在的行為是怎樣。」 「G哥，幫我根據這個需求開 Ticket。」 「G哥，幫我 Code Review這個PR。」 「G哥，幫我開發這張 Ticket。」 「G哥，客戶打API response內容有誤，幫我查可能的原因。」
因為 G哥知道我們團隊的 Workflow，也有整個專案的知識，所以他不是只回答問題，而是真的會按照團隊的 Workflow 去完成事情。像是 Developer 叫 G哥開發東西到一半，PM 收到客戶的需求變動，可以直接在對應的討論串裡請 G哥修改 Spec。G哥會更新對應的 Ticket，再啟動後面的開發修改。而且在整個過程裡，不同角色、不同人都可以隨時進來一起討論。
不跟你說，你可能還會以為 G哥就是公司的一個員工。
但這整件事，並不是把一個 Agent 接進 Chat channel 就完成了。 最近蠻多人問我：「你是怎麼推動整個團隊做 AI 轉型的？」我想了一下，這件事情真的不是一兩句話可以回答，所以我想把整個過程記錄下來。在這AI快速變動的時代，我想三個月後再回來看這紀錄，整個做法大概又會翻了一圈，就當是這個時間點的一個紀錄
一開始，我看到的是團隊能力的落差
我們有個團隊在負責一個很大的專案，大概有二十幾個 Module，跑了很多年。整個團隊快二十人，PM、Developer、QA，各種角色一起開發。
AI 出現之後，我非常鼓勵大家開始使用 AI。很快我就觀察到一件事情：那些本來就有好奇心、願意嘗試新工具，也會一直思考怎麼改善自己工作流程的人，AI 用得非常好，產出速度也快非常多。
但另外一群人沒那麼會用 AI，或者不知道怎麼把 AI 放進自己的工作流程。於是整個團隊開始出現蠻明顯的能力落差。更重要的是，我發現能力都累積在個人身上，而不是累積在團隊身上。有人變得很強，做事很快，但團隊沒有一起變強。這才是我真正想解決的問題。
第一個嘗試：打造團隊的 Knowledge Base
我先把整個專案的知識建立成一個 LLM Knowledge Base，再串上一個 Bot。大家有任何專案上的問題，都可以直接問 Bot。
這個 Knowledge Base 包含專案背景、Jira Ticket、Confluence，以及所有 Repository 的 Source Code。
這件事情的幫助很大。因為人腦根本記不住二十幾個 Module 的所有細節，很多歷史背景、Domain Knowledge、設計原因，以前需要找人或自己考古，現在都可以先直接問 Bot。
但後來我開始思考另外一件事：知識有了，團隊的工作流程，有沒有辦法一起加速？
我自己平常有不少 Side Project。在那些 Project 裡面，我花了一些時間打造自己的 AI Workflow。每次要開一個新的 Project，AI Agent 會自動幫我建立 Issue Board、建立環境、設定需要的東西。我只需要在 Discord 跟 AI Agent 討論我要做什麼，後面就可以由 Agent 自己開發、測試、部署。
那時候我就在想，如果我一個人可以這樣跟 AI Agent 工作，我能不能把這套方式複製給整個團隊？團隊缺的可能不只是 AI，而是一套一致的 Workflow 跟能力。每個人都在用 AI，但是每個人跟 AI 合作的方法完全不一樣。
第二個嘗試：先盤點團隊真正的 Workflow
所以我做的第二件事，不是直接導入更多 Agent，而是先盤點整個團隊平常到底怎麼工作。
我沒有一次找全部的人，而是先把各個角色的 Lead 找過來，一起把團隊真正的工作流程盤出來。不是某一個人的 Workflow，而是整個團隊的 Workflow。
以軟體開發來說，從需求進來到最後上線，整串 Flow 到底是怎樣，我們先把它盤點清楚。PM 怎麼開 Spec；Developer 怎麼 Review Ticket、怎麼 Design、怎麼開發、怎麼做 Code Review；QA 怎麼 Review Spec、怎麼驗證功能、怎麼測試。全部盤一次。
這裡面還有一個很重要的前置作業，就是建立共用的 Domain Knowledge 和 Rule。
大型專案一定有很多 Domain Knowledge：專有名詞、跨 Module 的關係、不同模組之間的依賴，以及很多當初的設計背景。這些東西光看 Code，根本看不出來。所以第一步，我先請大家把共用知識整理出來，建立整個 Project 共用的 Context。
第三個嘗試：建立共用的 Skill Repository
接著，我們開始建立團隊共用的 Skill Repository。這裡放的不是 Code，而是團隊做事情的方法。
PM 整理怎麼寫 Spec、怎麼拆 Ticket 的 Skill。這裡我們有很厲害的 PM，很主動地整理了非常多 Skill。Developer 整理怎麼 Review Ticket、怎麼 Design、怎麼做 TDD、怎麼開發、怎麼做 Code Review。QA 整理怎麼 Review Spec、怎麼驗證功能、怎麼測試。
而且每個 Skill 都會 Reference 前面建立好的 Domain Knowledge 和 Rule。換句話說，我們不只是在教 Agent 怎麼做事，而是在整理我們這個團隊認為「事情應該怎麼被做好」。
Workflow 裡的每一步需要什麼 Skill、應該產生什麼結果、怎麼交接給下一個角色，我們都先盤點出來。以我們團隊的做事方式來說，最後整個 Workflow 大概有十二步。
這段 Workflow 盤點是最花時間的，也是溝通最累的時候。因為一開始大家還看不到好處。
對很多人來說，眼前最重要的事情，就是先把自己手上的工作完成。這完全可以理解。畢竟整理 Workflow、寫 Skill、定義交接方式，短期看起來都不像是「今天一定要完成」的任務。
但 AI 轉型真正困難的地方就在這裡：如果每個人都只在自己的崗位裡最佳化，團隊能力就很難被沉澱下來。只有當一些人願意一起把方法整理出來，團隊才有機會從「個人變強」走向「整個團隊變強」。
當 Skill 慢慢建立起來之後，我們才進一步把整個 Workflow 定義清楚。
例如 PM 建立 Ticket 時，Ticket 必須 Reference Project Context，也要遵循團隊的 Coding Standard 和 API 標準。Ticket 建立完成後，Developer 會用 Review Spec 的 Skill 去 Review，QA 也會用自己的 Skill 去 Review。全部 Review 完、達成共識後，才進入 Developer 的開發流程。
開發過程同樣要遵循團隊的標準，例如 Coding Standard、API Standard、Error Response Standard、Error Code Standard。盤點這套流程，真正要釐清的是幾件事：
- 每一個角色在什麼時候介入，是 Agent，還是人？
- 每一個階段應該呼叫哪些 Skill？
- 每一個階段的產出是什麼？
- 要怎麼交接給下一步？
第四步：把 Agent 串進團隊平常工作的地方
Workflow 定義完成之後，我才把 Agent 平台的 Infra 建立起來，開始讓 Agent 串上 Chat channel。
我一直覺得，要讓 Agent 真的在團隊裡發揮作用，它一定要出現在大家平常討論、平常做事的地方。有的團隊用 LINE，有的用 Slack，有的用 Teams。不管是哪一個，你要讓 Agent 在 Chat channel 裡自然地跟團隊互動，而不是另外開一套沒有人會主動進去的工具。
當前面的知識、Skill、Workflow 和 Agent 都串起來後，才到了真正上線見真章的時候，也就是文章一開始提到的 G哥。大家現在可以直接跟 G哥一起工作，而不是只把它當成一個問答機器人。
這也帶來一個我原本就很想要的效果。因為大家都在 Chat channel 裡跟 Agent 對話，所以彼此可以看到別人怎麼跟 Agent 合作。不太會用的人，可以透過別人的互動自然地學習；比較會用的人看到哪裡有問題，也能直接跳進去協助。能力不再只藏在某一個人自己的 Prompt 或工作習慣裡。
以前，一個人能力很強，能力就在他身上。現在，知識被整理，Workflow 被標準化，Skill 被沉澱，Agent 也可以使用這些 Skill。
能力就開始累積在團隊身上。
這不代表什麼事情都交給 Agent
Human in the loop 要在什麼時候介入，也必須由團隊一起決定。
目前至少在我們的流程裡，Agent 開發完的東西，即使前面已經經過多個 Agent 的 Code Review 並且 Pass，最後還是需要人做最後的 Review 和 Merge。現在很多純 Vibe Coding 的專案，在沒有好的規範和流程下直接上 Production，最後改不動、甚至需要重寫的例子，我們也看過不少。
所以我們現在經手的大型專案，縱使很多開發工作都有 AI 協助，最後一步還是需要人來審核。目的很簡單，就是不要在 Production 出包，造成客戶跟我們自己的麻煩。不要小看這一步。
我看團隊 Review Agent 寫的東西時，即使前面多個 Agent 都說 Pass，Developer 還是會抓到 AI 過度設計，或是做了不該做的東西。我看 Developer 跟 Agent 的互動也蠻有趣的。Developer 看完後留一個 Code Review Comment，接著 AI Agent 就回去自己改、自己修。處理完後，再 Tag Developer 回來複審。
現在我們還是讓人介入。但在模型越來越聰明之後，未來是不是每一種 Ticket 都需要相同程度的人工作業，這就是一個很有趣的議題。目前我們也在嘗試把 Ticket 依照複雜度自動分級。低複雜度的 Ticket，未來可能讓人或 Agent 直接 Trigger 後續流程，自動開發、自動 Merge。
但這些都需要一步一步驗證，不是把 Agent 接上去就直接放手。
回頭看，我們大致做了四件事
- 打造團隊的 LLM Knowledge Base。
- 推動團隊共用的 Skill。
- 盤點並定義團隊 Workflow。
- 打造 AI Agent Infra，讓它真的進到團隊每天工作的地方。
很多人以為 AI Transformation 最難的是技術。我反而覺得不是。我覺得最難的是三件事情。
第一，是人的焦慮與視角
AI 轉型最難的地方，不是大家不努力，而是變化真的太快了。
很多人其實會有 AI 焦慮：不知道該從哪裡開始學，也不知道 AI 到底可以怎麼放進自己的工作裡。工具每天都在變，做法也一直翻新，對一個每天已經有很多工作要處理的人來說，這本來就不是一件容易的事。
另外一個挑戰，是崗位視角的限制。每個人站在自己的角色裡，最自然的反應就是先把眼前負責的事情做好。這不是不夠積極，而是每個位置能看到的問題範圍本來就不一樣。
所以 AI 轉型真正需要的，不只是叫大家多用 AI，而是幫大家看見：自己的工作方法，怎麼被整理成團隊可以共用的能力。
第二，是有沒有人願意站到更高一層做整合
在 AI 轉型裡，最難得的人，不一定是單點技術最強的人，而是願意把自己的視角往上拉一層的人。
他不只看自己手上的任務，也會開始看整個團隊怎麼工作：需求怎麼進來、Spec 怎麼寫、Developer 怎麼接、QA 怎麼驗證、Knowledge 怎麼沉澱、Skill 怎麼被下一個人重複使用。
這種事情很多時候不會立刻有掌聲，也不一定馬上看得到成果，甚至看起來還像是額外多做了很多事。但真正讓團隊變強的，常常就是這些願意做整合、願意整理方法、願意把個人經驗變成團隊資產的人。
如果你的團隊裡有這樣的人，請一定要好好珍惜。因為他帶來的影響力，遠遠超過他自己完成了多少任務。
第三，是根據實際結果不停調整
把第一版架起來，也許沒有想像中花那麼久。但 LLM 本來就不是固定產出，真正上線之後，後面一定需要不停地調整。隨著模型進步，很多原本需要的 Harness，之後也可能不再需要。
這會是一個長跑的過程。中間會不停試錯，團隊在心態上也要能接受：它很強大，但它不會完美。有問題的時候，大家要一起想辦法優化，而不是期待不知道哪一天會有人自己把它修好。
這幾個月，其實真的非常累
每天白天就是一堆 Office Operation、客戶會議，還有開不完的會。平常白天的瑣事加鳥事，就已經讓我累得像狗一樣。這些東西，很多都是晚上才有時間額外弄。
累歸累，但看到大家真的開始使用，看到一些同仁在已經打造起來的地基上，自己繼續優化、繼續把它往前推，我還是感到很欣慰，也很開心。因為這代表它已經不只是我自己在用的一套 Workflow，它開始變成團隊自己的能力。
如果你也正在推動公司的 AI 轉型
如果你是公司的老闆，我會強烈建議你自己要大量使用 AI，甚至自己 Build 一些東西。因為你真的用過，才會知道 AI 現在可以做到什麼、不能做到什麼。你對整間公司的 Context 掌握通常也比別人完整，更容易看到哪些地方能讓 AI 發揮價值。
如果你自己用得不多，那至少要找到一個真的很會用 AI，而且也「會」跟團隊溝通的人。給他足夠的空間和權限，讓他去推動。
AI 轉型，最後改變的不是工具。改變的是人怎麼跟AI協作。
而真正困難的，不是讓人承認 AI 很強，而是幫每個人看見：自己的工作方法，可以怎麼變成整個團隊的能力。
Right now, we have several AI agents living in our chat channel. These agents are led by G.
Every day, the team works with G directly:
“G, help me check how xxxx works now.” “G, help me create a ticket from this need.” “G, help me review this PR.” “G, help me build this ticket.” “G, the API response for a customer looks wrong. Help me find the possible reason.”
Because G knows our team workflow and also knows the project context, it does not only answer questions. It can really follow our workflow and get things done. For example, when a developer is building something, and a PM gets a change request from a customer, the PM can ask G inside the same thread to update the spec. G will update the ticket and then start the next development change. During the whole process, different roles and different people can join the discussion at any time.
If I did not tell you, you might think G is just another teammate in the company.
But this is not done by simply adding one agent into a chat channel.
Recently, many people have asked me, “How did you push the whole team to do AI transformation?” I thought about it, and this is not something I can explain in one or two lines. So I want to write down the process. In this fast-moving AI world, if I look back at this note three months later, the whole way of doing it may already have changed again. So this is just a record of this moment.
At first, I saw a gap in team ability
We have one team working on a very large project. It has more than twenty modules and has been running for many years. The team has almost twenty people, including PMs, developers, QA, and other roles.
After AI came out, I strongly encouraged everyone to start using it. Very soon, I noticed one thing: people who were already curious, willing to try new tools, and always thinking about how to improve their own workflow used AI very well. Their speed also became much faster.
But another group of people did not know how to use AI as well, or did not know how to put AI into their own workflow. So the team started to show a clear gap in ability. More important, I found that the ability was staying with each person, not becoming team ability. Some people became very strong and very fast, but the team did not become stronger together. That was the real problem I wanted to solve.
First try: build a team Knowledge Base
The first thing I did was build the project knowledge into an LLM Knowledge Base, and then connect it to a bot. When people had questions about the project, they could ask the bot directly.
This Knowledge Base included project background, Jira tickets, Confluence, and the source code of all repositories.
It helped a lot. No human brain can remember all the details of more than twenty modules. In the past, if we needed history, domain knowledge, or the reason behind a design, we had to ask someone or dig through old records. Now we could ask the bot first.
But later, I started to think about another question: now that we had the knowledge, could we also make the team workflow faster?
I have many side projects. In those projects, I spent time building my own AI workflow. Every time I start a new project, the AI agent can help me create the issue board, build the environment, and set up what is needed. I only need to discuss what I want to build with the AI agent in Discord. After that, the agent can build, test, and deploy by itself.
At that time, I started to think: if I can work with AI agents this way by myself, can I copy this way of working to the whole team? Maybe the team does not only need AI. Maybe it needs one shared workflow and one shared way of building ability. Everyone is using AI, but everyone works with AI in a different way.
Second try: map the team’s real workflow first
So the second thing I did was not to add more agents right away. I first mapped how the team really works every day.
I did not bring everyone in at once. I first asked the leads from each role to join, and we mapped the real workflow of the team together. Not one person’s workflow, but the team’s workflow.
For software development, we mapped the whole flow from a new request to release. How does the PM write the spec? How does the developer review the ticket, design, build, and do code review? How does QA review the spec and test the feature? We went through the full flow once.
There was also one important step before this: building shared domain knowledge and shared rules.
A large project always has a lot of domain knowledge: special terms, links between modules, dependencies between modules, and the background of many old design choices. You cannot see these things only by reading code. So the first step was to ask the team to write down shared knowledge and build shared project context.
Third try: build a shared Skill Repository
Next, we started to build a shared Skill Repository for the team. This was not for code. It was for how the team does work.
PMs wrote skills for writing specs and breaking work into tickets. We have very strong PMs, and they took the lead to write many skills. Developers wrote skills for reviewing tickets, designing, doing TDD, building features, and doing code review. QA wrote skills for reviewing specs, checking features, and testing.
Each skill also refers to the domain knowledge and rules we built earlier. In other words, we were not only teaching the agent how to do tasks. We were writing down how our team believes work should be done well.
For each step in the workflow, we mapped which skills are needed, what result should be created, and how the work should be handed to the next role. In our team, the final workflow has about twelve steps.
This workflow mapping was the most time-consuming part. It was also the hardest part to talk through, because at first, people could not see the value yet.
For many people, the most important thing in front of them is to finish the work they already have. This is easy to understand. Writing workflows, writing skills, and defining handoff rules do not look like tasks that must be finished today.
But this is where AI transformation gets hard. If everyone only improves the work inside their own role, team ability will be hard to build. Only when some people are willing to write down the way of working can the team move from “some people become stronger” to “the whole team becomes stronger.”
After the skills slowly took shape, we then defined the full workflow more clearly.
For example, when a PM creates a ticket, the ticket must refer to the project context. It must also follow the team’s coding standards and API standards. After the ticket is created, developers use the review spec skill to review it, and QA also uses their own skill to review it. Only after everyone reviews it and reaches agreement do we move into development.
The development process also follows team standards, such as coding standards, API standards, error response standards, and error code standards. When we mapped this flow, we were really trying to answer a few questions:
- At each step, who should join: an agent, or a person?
- Which skills should be used at each step?
- What should each step produce?
- How should the work be handed to the next step?
Fourth step: put the agent where the team already works
After the workflow was clear, I built the agent platform infra and connected the agent to the chat channel.
I have always believed that if an agent is going to be useful in a team, it must show up in the place where people already talk and work. Some teams use LINE. Some use Slack. Some use Teams. No matter what tool you use, the agent has to work naturally inside the chat channel. It should not be another tool that no one opens.
After the knowledge, skills, workflow, and agent were connected, we finally reached the stage I mentioned at the beginning: G. Now people can work with G directly, not just use it as a Q&A bot.
This also gave us the result I wanted from the start. Because everyone talks with the agent in the chat channel, people can see how others work with the agent. People who are not good at using AI yet can learn from other people’s conversations. People who are better at using AI can also jump in and help when they see a problem. Ability is no longer hidden inside one person’s prompt or work habit.
In the past, when one person was strong, the ability stayed with that person. Now, knowledge is written down, the workflow is made clear, skills are saved, and agents can use those skills.
Ability starts to build up inside the team.
This does not mean we give everything to agents
The team still needs to decide when a human should be in the loop.
At least in our current process, even if an agent builds something and several other agents already review it and say it passes, a human still does the final review and merge. We have seen many pure vibe coding projects that went to production without good rules or process. Later, they became hard to change, or even had to be rebuilt.
So for the large projects we handle now, even when AI helps with a lot of development work, the last step still needs human review. The reason is simple: we do not want production issues that hurt our customers or ourselves. Do not treat this step as small.
When I watch developers review code written by agents, even if several agents already said it passed, developers can still find cases where AI over-designed something or built something it should not have built. I also find the way developers work with agents interesting. A developer leaves a code review comment, then the AI agent goes back to fix it by itself. After it is done, it tags the developer to review again.
We still keep humans in the loop now. But as models get smarter, maybe not every ticket will need the same level of human work in the future. This is an interesting question. We are also trying to group tickets by how hard they are. In the future, low-complexity tickets may be started by a person or an agent, and then built and merged automatically.
But all of this has to be tested step by step. You cannot just connect an agent and let it go.
Looking back, we mainly did four things
- Built a team LLM Knowledge Base.
- Built shared team skills.
- Mapped and defined the team workflow.
- Built AI agent infra and put the agent into the place where the team works every day.
Many people think the hardest part of AI transformation is the technology. I do not think so. I think the hardest parts are these three things.
First: people’s worry and point of view
The hardest part of AI transformation is not that people do not work hard. It is that things are changing very fast.
Many people have AI worry. They do not know where to start learning, and they do not know how to use AI in their own work. Tools change every day. Ways of working also keep changing. For a person who already has a lot of daily work, this is not easy at all.
Another challenge is the limit of each role’s point of view. When people stand inside their own role, the most natural thing is to first finish the work in front of them. This does not mean they are not trying hard enough. It only means each role can see a different range of problems.
So AI transformation is not only about asking everyone to use AI more. It is about helping people see how their way of working can become shared team ability.
Second: whether someone is willing to step up and connect the pieces
In AI transformation, the rare person is not always the one with the strongest single skill. It is the person who is willing to look one level higher.
This person does not only look at the task in their own hands. They also start to look at how the whole team works: how requests come in, how specs are written, how developers take work, how QA checks work, how knowledge is saved, and how a skill can be used again by the next person.
This kind of work often does not get applause right away. It may not show results right away. It may even look like extra work. But the things that truly make a team stronger are often these: connecting the work, writing down the method, and turning personal experience into a team asset.
If you have people like this in your team, please take good care of them. Their impact is much bigger than the number of tasks they finish by themselves.
Third: keep changing based on real results
Building the first version may not take as long as you think. But LLM output is not fixed. After the system is really used, it will need many changes. As models improve, some harnesses we need today may not be needed later.
This is a long run. There will be many trials and mistakes. The team also needs to accept this: AI is powerful, but it is not perfect. When there is a problem, everyone needs to improve it together, not wait for someone to fix it someday.
These months were really tiring
Every day, I had office operations, customer meetings, and meetings that never seemed to end. The small problems and annoying things during the day already made me feel like a dog. A lot of this AI work could only be done at night.
It was tiring. But when I saw the team really start to use it, and saw some teammates keep improving it on top of the base we built, I felt happy. Because it meant this was no longer only my own workflow. It was starting to become the team’s own ability.
If you are also pushing AI transformation in your company
If you are a business owner, I strongly suggest that you use AI a lot yourself, and even build some things yourself. Only when you really use it will you know what AI can do now and what it cannot do. You also usually understand the context of the whole company better than others, so it is easier for you to see where AI can create value.
If you do not use AI much yourself, then at least find someone who is really good at using AI and also good at talking with the team. Give that person enough room and enough authority to push it forward.
AI transformation does not change only the tools. It changes how people work with AI.
And the real hard part is not making people admit that AI is powerful. It is helping each person see how their way of working can become the team’s ability.