iT邦幫忙

ai開發工作流相關文章
共有 21 則文章
鐵人賽 AI Engineering DAY 21

技術 Day 21:案例——一個 agent 違反只讀不寫指示,但改的內容剛好是對的

前言:結果是對的,這件事就該算了嗎? 昨天講完「只讀不寫」這條規則該怎麼寫進委派指令,今天要面對一個更棘手的情況:規則寫得再明確,還是有 agent 會違反它—...

鐵人賽 AI Engineering DAY 20

技術 Day 20:為什麼要限制 agent「只讀不寫」——查核跟修正分開的理由

前言:反正 agent 看得懂問題,順手改掉不是更有效率嗎? 「派一個 agent 去查文章裡有沒有技術錯誤,它看到問題,順手改掉不就好了,何必還要多一趟『回報...

鐵人賽 AI Engineering DAY 19

技術 Day 19:案例——兩個 agent 同時寫同一個檔案,事後怎麼比對取捨

前言:明明分工清楚,怎麼還是撞在一起? 「我已經把任務拆好、每個 agent 各自負責不同的範圍了,應該不會重複吧?」 如果你也這樣想過,先別急著放心。昨天講的...

鐵人賽 AI Engineering DAY 18

技術 Day 18:案例——一個 agent 逾越指派範圍,自己動手做了別人的工作

前言:委派出去的任務,範圍是誰畫的? 「我只是叫它做 A,怎麼連 B、C、D 都一起做了?」 這句話聽起來像是在稱讚一個很主動的下屬,但套在委派給獨立 agen...

鐵人賽 AI Engineering DAY 17

技術 Day 17:為什麼要委派給獨立 agent——不是「分工」這麼簡單

前言:委派不就是把工作拆給別人做嗎? 「多 agent 協作聽起來很潮,但說穿了不就是把一件事拆成好幾份、分別叫不同的 agent 去做嗎?跟找幾個工讀生分工有...

鐵人賽 AI Engineering DAY 16

技術 Day 16:案例——某類規則從「每次人工複查都漏」到寫成自動化檢查工具的過程

前言:明明每次都有檢查,為什麼還是漏掉? 「我們每次發文前都會請人再看一遍,怎麼還是會漏掉不該出現的東西?」 這是很多團隊在導入某種內容規範(不管是去識別化、格...

鐵人賽 AI Engineering DAY 15

技術 Day 15:Skill 附帶可執行工具(script):把機械式檢查自動化

前言:寫進 skill 裡的規則,AI 真的會照做嗎? 「這條規則我已經寫進 skill 了,AI 應該會照著做吧?」 這句話聽起來很合理,卻藏著一個容易被忽略...

鐵人賽 AI Engineering DAY 14

技術 Day 14:案例——把記憶跟 skill 搞混,同一條規則兩個地方各寫一次

前言:規則寫兩份,有什麼問題? 「這條規則重要,我在記憶裡記一份,順手也寫進 skill 裡,兩邊都有總比漏掉好吧?」 聽起來是在加保險,實際上是在埋一顆定時炸...

鐵人賽 AI Engineering DAY 13

技術 Day 13:CLAUDE.md vs Skill vs Memory——三層分工怎麼不互相打架

前言:三個地方都能寫規則,到底該寫在哪? 「這條規則到底該放進 CLAUDE.md、寫成一支 skill,還是存進記憶就好?」 這個問題聽起來瑣碎,但答錯的代價...

鐵人賽 AI Engineering DAY 12

技術 Day 12:project 記憶會過期——怎麼設計「引用前先驗證」的紀律

前言:記憶裡寫的,現在還是真的嗎? 「記憶裡明明記著這個功能已經做完了,AI 怎麼還在問我要不要重做一次?」 如果你反過來遇到另一種情況——AI 信心滿滿地說「...

鐵人賽 AI Engineering DAY 11

技術 Day 11:案例——記憶過期的真實教訓

前言:記憶系統最怕的不是記錯,是記得太久 「AI 的記憶系統已經照昨天講的『深層記憶』寫法在維護了,判斷邏輯、否決理由、適用邊界都記了,這樣應該就夠可靠了吧?」...

鐵人賽 AI Engineering DAY 10

技術 Day 10:記憶要記「為什麼」,不是只記「使用者不喜歡什麼」

前言:記下來就好了,為什麼還要講究怎麼記? 「AI 被糾正過的事,記下來下次不要再犯不就好了嗎?講究記憶要怎麼寫,是不是想太多了?」 聽起來理所當然,但只要真的...

鐵人賽 AI Engineering DAY 9

技術 Day 09:案例——一個 feedback 記憶怎麼從「被糾正」變成「規則」

前言:被糾正過一次,下次就不會再犯了嗎? 「AI 這次被我糾正了,它應該已經『學到』了吧?下次遇到類似情況,總不會再犯同樣的錯了?」 如果你也這樣期待過,大概很...

鐵人賽 AI Engineering DAY 8

技術 Day 08:持久記憶系統的四種類型——user/feedback/project/reference

前言:反正都是「記住的東西」,分類有那麼重要嗎? 「AI 的長期記憶不就是一堆筆記嗎?想到什麼就記下來,需要的時候撈出來用,幹嘛還要分類?」 第一部講完 CLA...

鐵人賽 AI Engineering DAY 7

技術 Day 07:Skill 的「定位」段落——為什麼比規則本身更重要

前言:規則寫得夠細,還會出什麼問題? 「一支 skill 只要把規則寫得夠詳細、夠具體,AI 應該就會用得準吧?」 這句話對了一半。規則寫得詳細,確實能讓 AI...

鐵人賽 AI Engineering DAY 6

技術 Day 06:案例——一支 skill 從無到有的誕生過程

前言:Skill 是規劃出來的,還是長出來的? 「要幫 AI 寫一支 skill,是不是要先坐下來,把這個領域的規則想清楚、列完整,再一次寫好?」 如果你也這樣...

鐵人賽 AI Engineering DAY 5

技術 Day 05:Reference 型 vs Task 型 skill——什麼時候用哪一種

前言:反正都是「給 AI 讀的規則」,分那麼細幹嘛? 「Skill 不就是一份寫給 AI 看的說明文件嗎?裡面寫規則也好、寫步驟也好,AI 都看得懂,有必要分成...

鐵人賽 AI Engineering DAY 4

技術 Day 04:Skill 的本質——把一次性經驗提煉成可重複套用的規則

前言:寫一份文件,跟寫一支 Skill,差在哪裡? 「不就是把規則寫成一份文件嗎?跟寫在 README 或內部 wiki 有什麼不一樣?」 這是我剛開始用 Sk...

鐵人賽 AI Engineering DAY 3

技術 Day 03:案例——CLAUDE.md 太長會發生什麼事

前言:規則寫進去了,為什麼還是沒被遵守? 「這條規則我明明寫進 CLAUDE.md 了,AI 怎麼還是沒照著做?」 如果你也問過這句話,先別急著懷疑是 AI 不...

鐵人賽 AI Engineering DAY 2

技術 Day 02:CLAUDE.md 是什麼——全站規範 vs 特定情境規則的分界

前言:不就是一份「給 AI 看的說明文件」嗎? 「CLAUDE.md 不就是把專案規範寫一份文件丟給 AI 讀嗎?跟寫 README、寫 wiki 有什麼本質上...

鐵人賽 AI Engineering DAY 1

技術 Day 01:AI 開發雜記——為什麼工具本身也要被設計

前言:CLAUDE.md 不就是寫一份文件給 AI 看嗎,有什麼好設計的? 「CLAUDE.md、Skill、記憶系統,講白了不就是幾份給 AI 讀的說明文件嗎...