「個股要點」— 投資組合總表 完整規格（逐欄位詳解）

帳戶彙總（列 61–80）— 完整規格（含逐格核實）

查證方法：本節所有公式與數值均直接由 data/_recovered_基富投資1.xlsx 的 個股要點 工作表 XML（xl/worksheets/sheet4.xml，rId4）解析取得（cached value + <f> 公式節點），並交叉比對 xl/comments2.xml（儲存格註解）與 xl/worksheets/_rels/sheet4.xml.rels（超連結關係）。跨表引用已用同樣方法查證 贖回損益 工作表（工作簿：基富投資1.xlsx，264×18）的對應儲存格，確認引用方向與數值完全吻合（見下方「完整範例 A」）。

1. 這個區塊的角色

列 61–80 不是一個乾淨獨立的區塊，而是三種用途疊在同一段列號上：

1. 列 4–69（A–F 欄）是「帳戶價值歷史日誌（新到舊）」的尾段延續（列 61–69 仍是這個日誌的一部分，日期落在 2023-12-24～2024-03-11）；
2. 在這段日誌的空白欄位（N、T、U、BO、BP、BQ、BR、BS、BU、BV）上，作者疊放了「帳戶層級即時彙總」——匯率、USD 總計、配息次數合計；
3. 列 70–80 是一個獨立的「儀表板小區塊」：帳號備忘、流程備忘、TWD 總計、以及與 贖回損益 表雙向互算出的帳戶預估損益，然後在列 81 銜接回第二段歷史日誌（列 81–538，早期日誌）。

因此工程團隊若要把這個區塊系統化，不能假設「列 61–80 = 一張乾淨的彙總表」，必須先把「歷史日誌尾段」與「彙總儀表板」兩層拆開。

2. 完整逐格對照表

3. 完整範例 A：個股要點 ↔ 贖回損益 的雙向公式鏈（已逐格核實）

這是本區塊最重要、也最容易搞反方向的關係。實際查證結果：四個原始輸入格由 個股要點 → 贖回損益，兩個計算結果格再由 贖回損益 → 折返 個股要點，不是單一方向：

``` 個股要點!A80 = 46135 ─────────────► 贖回損益!K2 = 46135 （結算日期） 個股要點!U63 = 0.0315 ─────────────► 贖回損益!L6,M6 分母 （匯率折算） 個股要點!D80 = 10,104,436 ─────────► 贖回損益!N6 = 10,104,436 （浮動盈虧台幣） 個股要點!C78 = 48,737,730 ─────────► 贖回損益!L9 = 48,737,730 （目前投資成本台幣）

贖回損益 內部計算（列 4–10 交易明細硬編碼加總，見 docs/excel/03-贖回損益.md）： L4=24,180,695（台幣小計） L5=2,179,686.69（美金小計） L6 = L4 + L5/U63 = 24,180,695 + 2,179,686.69/0.0315 = 93,377,097.86 M4=3,647,386 M5=29,645.4 M6 = M4 + M5/U63 = 3,647,386 + 29,645.4/0.0315 = 4,588,509.81 （累計已實現台幣） L8 = L6-M6 = 88,788,588.05；N8 = M6/L8 = 0.05167904919 L9 = 48,737,730（← 個股要點!C78） N9 = N6/L9 = 10,104,436/48,737,730 = 0.2073226636 L10 = M6 + N6 = 4,588,509.81 + 10,104,436 = 14,692,945.81 （帳戶預估淨損益＝已實現＋未實現） N10 = L10/L9 = 14,692,945.81/48,737,730 = 0.3014696378 （帳戶預估總報酬率）

贖回損益!L10 = 14,692,945.81 ──────► 個股要點!I78 = 14,692,945.81（帳戶預估淨損益，label 在 I76） 贖回損益!N10 = 0.3014696378 ──────► 個股要點!I77 = 0.3014696378 （帳戶預估總報酬率，僅靠儲存格註解標示） ```

以上每一個數字都已在兩張表的原始 XML 中核對到位、完全一致，I77 的意義（帳戶預估總報酬率）是由儲存格註解（作者 JSmart：「帳戶預估總報酬率」）直接證實，而非猜測。

4. 完整範例 B：USD 總計與市值佔比自我檢驗（含台幣基金換算）

以第 52 列（野村全球品牌基金-累積類型新臺幣計價，代碼 NOM010，幣別=台幣）為例：

• BP52（投資本金原幣）= 346,110、BQ52（參考市值原幣）= 364,243
• BS52 = (BQ52*$U$63)/$BQ$63 = (364243 × 0.0315) / 1,668,436.76 = 0.006876889059（實際快取值一致，經人工重算精確到小數點後 10 位完全吻合）→ 此基金約佔美金基準總市值的 0.688%
• BT52 = RANK(BS52,$BS$3:$BS$58,0) = 40（市值排名第 40）

而 BS63 = SUM(BS3:BS51)+SUM(BS52:BS58) ≈ 1：因為 $BQ$63（分母）本身就是 SUM(BQ3:BQ51)+SUM(BQ52:BQ58)*U63，與 BS 欄的分子加總在數學上互為同一組數字，這個「=1」檢驗在結構上必然成立（只要沒有 #DIV/0!／空值等錯誤），並非獨立於商業邏輯之外的驗證——它真正能抓到的是「BQ 欄或 U63 有沒有壞掉/被清空」這類技術性錯誤，而不是金額算錯。工程團隊若要重建這個「自我檢驗」，應理解它的實際作用範圍。

5. 發現的異常、硬編碼與工程注意事項

1. BV62 公式錯誤，非單純硬編碼：BU61/BU62 標籤是「合計USD」/「合計台幣」一對，BV61=SUM(BV3:BV51)=78（USD 基金列 3–51 的配息次數合計，正確）；但 BV62 的公式是 =BV22，指向一個完全不相關、內容為空的儲存格，而不是預期的 SUM(BV52:BV58)（TWD 基金列 52–58）。目前因為 BV52:BV58 剛好全部是空白，BV62 顯示的 0 碰巧「看起來正確」，但只要日後在任何一檔台幣基金填入配息次數，這格也不會更新——這是一顆已經存在但尚未爆的計算錯誤，重建系統時不要照抄這個公式，應改為 SUM(BV52:BV58)。

1. BS71 = SUM(BV5:BV53) = 66 與 BV61 = SUM(BV3:BV51) = 78 是兩套不同範圍、不同結果的「配息次數合計」，彼此相差 2 列的起訖點，且無任何欄位標籤說明 BS71 是什麼、為何存在第二套算法。這兩個數字目前不一致（66 對 78），工程團隊須向業主確認何者才是正確的「累計配息次數」定義，不能兩者都保留當作各自獨立的真相來源。

1. B78/C78（台幣手動總計）與 BP63/BQ63（USD 公式加總換回台幣）彼此不對帳：把 BQ63 除以 U63 換算回台幣得 52,966,246，但 B78（手動維護的台幣總參考市值）是 58,842,166，相差約 588 萬台幣（約 11%，以 BQ63/U63 為基準計算）；BP63/U63=46,738,160 對 C78=48,737,730，相差約 200 萬（約 4.3%，以 BP63/U63 為基準計算）。追查日期發現原因：BP63/BQ63 目前對齊的是歷史日誌列 4 的快照日 2026-04-14（逐筆基金 BP3:BQ58 最後更新的日期），而 A80/B78/C78/D80 這組「儀表板」數字對齊的是 2026-04-23（晚 9 天）。也就是說：逐筆基金明細（列 3–58）與帳戶層級 TWD 總計（列 78/80）是兩條各自獨立維護、更新頻率不同步的資料流，兩者之間沒有任何公式互相勾稽。系統化時必須決定：究竟以逐筆加總為準，還是以手動輸入的帳戶總覽為準，並補上兩者的核對機制，否則會出現「畫面上兩個總市值對不起來」的使用者疑惑。附帶一提：B78-C78 = 58,842,166-48,737,730 = 10,104,436，與 D80 完全相等，證明 B78/C78/D80 這三格彼此內部是自洽的，只是跟 BP63/BQ63 那一組不自洽。

1. B80/C80 應該有值卻是空的：列 79（A79:E79）是「日期/總參考市值/庫存成本/未實現損益/總報酬率」的欄位標頭，理應對應列 80 起逐列的資料序列（這也確實是列 81 以後 B/C 欄的用法，例如 B83=58,842,166、C83=48,737,730 與今天的 B78/C78 完全相同）。但當前這一筆「今天」的資料被放在標頭「上方」的 B78/C78，而不是標頭「下方」該有的 B80/C80，造成 B80/C80 是空白。若工程團隊照著「標頭下面接資料」的直覺去解析這個表，會漏抓當日的市值/成本。

1. 標籤與數值錯位（I76/I77/I78）：I76="帳戶預估淨損益" 這個標籤實際對應的數值在兩格之後的 I78（14,692,945.81），中間的 I77（0.3014696378，帳戶預估總報酬率）反而沒有任何儲存格文字標示它是什麼，只能從儲存格「註解」（不會顯示在列印/畫面上，只有把滑鼠移上去才看得到）得知它是「帳戶預估總報酬率」。若不查註解，很容易誤把 I77 當成「帳戶預估淨損益」（因為它離 I76 標籤最近）——事實上 I77 是報酬率、I78 才是金額。

1. 列 77 的 D/E/G 不是公式，是打字寫出來的公式字串：D77、E77、G77 型態是共用字串（t="s"），內容雖然長得像 =B47-C47，但它是「文字」，Excel 不會計算它，純粹是作者留給自己看的「這欄的算法備忘」（而且引用的列號 47 跟目前資料所在位置也對不上，明顯是很久以前殘留、範例列號沒有跟著資料搬動而更新）。工程團隊如果寫程式掃描整份 Excel 抓公式，務必把這種「文字型公式」與真公式（I77/I78/F79/BP63…）分開處理，否則會誤判。

1. A70="全部基金" 的更新時間戳記明顯過期：合併儲存格 B70:C70 顯示 2024/08/16 03:21更新，比周邊所有其他日期（2026 年 2–4 月）舊了超過一年半，且 A70 本身沒有超連結（整張工作表唯一的超連結只有 U64 那個兆豐銀行匯率試算頁面，已用 sheet4.xml.rels 核實）。這格看起來是很久以前某次「全基金總覽」相關作業留下的殘留標記，沒有隨後續維護更新，建議工程團隊不要把它當作有效的「最後更新時間」來源。

1. A74 內文有一個孤立反引號字元：申購>等待扣款>扣款成功 >交易日期＞交易完成等待單位數，反引號夾在「扣款成功」與「>交易日期」之間，是打字時的手誤殘留，語意上應視為單一連續字串，只是多了一個雜訊字元。

1. R80/S80/T80 不是單一快照，而是一張連續 16 列（列 80–95）、隱藏在儀表板正下方的「月結歷史清單」，且與列 3–58 的 R/S/T 欄位語意完全不同：列 3–58（逐檔基金明細區）裡 R=基金號碼、S=Yahoo 代號、T=P 與 MA20 乖離排序；到了列 78 起（帳戶彙總區）R/S/T 變成月獲利／月平均成本／月獲利率（標頭在 R78/S78/T78，期間標籤標頭在 N78）。經逐列查證（直接比對 R80:T95 與下方主日誌列 81–538 中 J/K/L 公式列的快取值），確認 R80:T95／N80:N95 都是無公式、人工逐月往下貼的資料，而且每一列都能在主日誌找到完全相同的公式來源，不是只出現一次：

• R80/S80/T80 = 3,992,105.367 / 39,728,154.56 / 0.1004855476 ＝ J94/K94/L94（J94=I94-I119）
• R81/S81/T81 = 605,105.8348 / 40,991,969.91 / 0.01476157004 ＝ J119/K119/L119（J119=I120-I143）
• R82/S82/T82 = 878,369.5785 / 37,529,963.23 / 0.02340448812 ＝ J142/K142/L142（J142=I143-I169）
• R83/S83/T83 = 1,695,420.612 / 34,596,805.46 / 0.04900512025 ＝ J168/K168/L168（J168=I171-I196）
• R84 = 308,123.3331 ＝ J193（J193=I196-I221）

（以上五組數值與公式來源已逐格核對完全一致；R85~R95 依相同週期模式延續，列 96 起變回空白，共 16 列。）也就是說，R80:T95 這張小表與下方主日誌裡每隔約 25 列出現一次的 J/K/L 公式列，其實是同一份「每月結算」資訊的兩種呈現方式——一份留在主日誌用公式即時算，另一份被人工搬到儀表板正下方，方便一眼看到近 16 個月的月結趨勢，並非互不相干、也不是「複製一次就結束」。系統化時若只處理 R80/S80/T80 這一列，會漏掉 R81:T95另外 15 列的月結歷史；若把它們誤判成與列 3–58 的 R/S/T（基金號碼/Yahoo 代號/乖離排序）同一 schema，也會出錯——必須改以「列號區段＋欄位字母」的組合定義欄位語意，並額外辨識「R80:T95 月結歷史小表」這個獨立子結構（含 N80:N95 的期間標籤）。

1. U62（46126＝2026-04-14）的語意是推論出來的，並非有明確標籤：本文將其標註為「最近定期定額日」是因為它與歷史日誌最新一筆 A4（2026-04-14）完全相同，且緊鄰 N62「每次定期定額 計1550+450」這則備忘，兩者放在同一列，合理推測 U62 記錄的是「最近一次定期定額扣款所觸發、對應到日誌那一筆更新的日期」。但工作表裡沒有任何文字標籤直接寫著「最近定期定額日」，這是本文根據上下文與數值巧合做出的合理推斷，並非查到明確標籤，特此註明查證等級。

1. 列 81 是第二段歷史日誌（列 81–538）的斷裂起點，緊接在本區塊之後：D81=0、E81=#DIV/0!（因為 C81 空白導致除以零，是一個真實存在的公式錯誤，會被 Excel 顯示為錯誤值），且 G81 的公式是 =(B81-B100)-(C81-C100)（往後跳 19 列，取代一般模式的往後跳 1 列 =(B_r-B_{r+1})-(C_r-C_{r+1})），顯示作者手動修補過這一列以跳過缺資料的區間。雖然列 81 已超出本次要求的列 61–80 範圍，但它是本區塊（尤其是 A80/B80/C80/D80 那個斷點）銜接下一段資料的直接後果，建議工程團隊在重建「早期日誌」表格時一併留意這個已知的斷裂點與錯誤值。

6. 與其他工作表關係總結（方向已逐格核實）

這是一個「單向資料流形成一個非循環的兩段接力」：個股要點 先把四個原始輸入（結算日期、匯率、庫存成本、未實現損益）餵給 贖回損益；贖回損益 在自己的彙總區（K2:N10）把已實現（來自它自己列 4 起的交易明細硬編碼加總）與未實現（引用回來的 D80）合併算出兩個最終指標；最後這兩個指標再被 個股要點!I77/I78 引用回來顯示在儀表板上。方向不是單純的「A 表抓 B 表」，而是「A 表給原料，B 表加工，A 表再顯示成品」，工程團隊若只查了 docs/excel/03-贖回損益.md 的 K2/L9/N6 就以為全部都是「贖回損益抓個股要點」，會漏掉 I77/I78 這個反向的部分。

7. 資料來源與查無資料項目

• 所有公式與快取值：直接解析 data/_recovered_基富投資1.xlsx 的 xl/worksheets/sheet4.xml（個股要點）與相應 贖回損益 sheet 的 XML，逐格比對（非僅依賴 tools/out/基富投資1/個股要點.txt 的摘要，該 dump 檔的「表尾區」只涵蓋 r496 之後，不含列 61–80，本節數字全部另行以 Python 腳本直接查詢原始 XML 取得）。
• 儲存格註解：xl/comments2.xml，已確認整份工作表在列 55–85 範圍內僅有 U63（作者 USER：「使用即期匯率」）與 I77（作者 JSmart：「帳戶預估總報酬率」）兩則註解，其餘儲存格皆無註解可查。
• 超連結：xl/worksheets/_rels/sheet4.xml.rels，確認整份工作表僅有一個超連結（U64→兆豐銀行網址），A70「全部基金」並非超連結。
• 查無資料：U62「最近定期定額日」與 N80「260409~260310」這類期間代碼的確切生成規則（是否由公式一次性算出後轉貼為文字、或全程手動輸入）查無公式痕跡佐證，只能確認它們目前是純文字/數值，本文已如實標註為「推論」而非「證實」。

稽核結果摘要：對草稿中提到的每一個儲存格/公式（A61:F69 全區、BU61/BV61、BV62 及其引用的 BV22、U62 與 A4 的日期對照、T63/U63/BO63/BP63/BQ63/BR63/BS63 全部原始快取值精度、U64 超連結、A70/B70 合併儲存格、BS71、A72–A75 文字內容、I76/I77/I78 三格與 I77 儲存格註解、B78/C78/D78/F78–T78 標頭、F79、A79–E79、A80/B80/C80/D80/N80/R80/S80/T80、列 81 的 D81/E81/G81 錯誤公式，以及 贖回損益 工作表 K2/L4/L5/L6/L8/L9/L10/M4/M5/M6/N6/N8/N9/N10 的公式與快取值）皆直接以 Python 解析原始 XML 逐一核對，全數與草稿相符，包括浮點精度（如 BS63=0.99999999999999978、I78=14692945.80952381）與跨表引用方向（確認是 贖回損益 抓 個股要點 的四個原始輸入，個股要點!I77/I78 再反向抓 贖回損益!N10/L10，與已知事實一致，未搞反方向）。

唯一發現並修正的問題：草稿第 5 節「異常 9」與表格中 R80/S80/T80 的描述原本稱其為「一次性快照」，暗示只在列 80 出現一次、不像 J/K/L 每月規律出現。經逐列核對 R80:T95 與 N80:N95，發現這其實是一張連續 16 列的「月結歷史清單」（無公式、人工逐月貼上），且每一列都能在下方主日誌列 81–538 找到對應的 J/K/L 公式列（已逐格核對 R80=J94、R81=J119、R82=J142、R83=J168、R84=J193 五組數值與公式來源完全一致）。已修正表格中的 N80/R80/S80/T80 敘述與第 5 節第 9 點的完整說明，避免工程團隊誤以為只需處理 R80/S80/T80 這一列就等於抓到全部「月結歷史」資料，遺漏 R81:T95 另外 15 列。

其餘部分（已知關鍵事實的涵蓋度、敘述清晰度、引用方向正確性）均無問題，維持原文不變。 </markdown>

帳戶價值歷史日誌（列 4–69 與列 81–538）

工作簿 基富投資1.xlsx，工作表「個股要點」（556 列 × 103 欄，對應 xl/worksheets/sheet4.xml）。 以下內容全部以 backend/.venv/Scripts/python.exe 直接解析原始 data/_recovered_基富投資1.xlsx 的 sheet4.xml／shared strings 覆核；xl/worksheets/_rels/sheet4.xml.rels 確認 xl/comments2.xml 是「個股要點」自己的儲存格註解檔（與「贖回損益」工作表〔xl/worksheets/sheet3.xml〕是 兩個不同的檔案），第 5 節「與贖回損益的循環參照鏈」是另外直接解析 sheet3.xml 交叉比對； 未特別註明「推測」的數字/公式都已用程式重算驗證。

1. 這個區塊的角色

這兩段（列 4–69、列 81–538）是整份「個股要點」表裡唯一的時間序列：其餘 103 欄 大多是「當下快照」（每列一檔基金的最新指標、排行、投資建議）。這兩段則是分析師 每次結算時，在同一批欄位最上方插入新的一列，把「當時的帳戶總市值 / 總成本」存成 歷史紀錄，藉此算出「這次結算比上次賺了多少」「累積賺了多少」「月報酬率」等，是 整個工作簿唯一能回答「帳戶隨時間怎麼變化」的地方。兩段格式、幣別、更新頻率都不同， 彼此獨立維護，不是同一個公式鏈的延伸。

2. 版面地圖（含列 69–81 的「夾層」）

這兩段歷史日誌實際上跟另一張表（列 3–58 的「基金排行 / 加碼贖回建議」表，欄 L、N–CU）共用列號，閱讀原始檔案時很容易搞混，先把整體版面列出來：

3. 段一：列 4–69（A–F，USD，由新到舊）

表頭（列 2）：A=日期 | B=投資本金 | C=參考市值 USD | D=期間獲利 USD | E=累積獲利 USD | F=總報酬率

B/C 的真正來源（已驗證）：B、C 兩欄雖是「純值」沒有公式，但可以證明它們是 分析師手動把同工作表 BP63／BQ63（基金排行表最下方的「總投資本金 USD」／ 「總參考市值 USD」自動加總儲存格）貼過來的快照：

`` BP63 = SUM(BP3:BP51)+SUM(BP52:BP58)*U63 → 值 1472252.0449999999 BQ63 = SUM(BQ3:BQ51)+SUM(BQ52:BQ58)*U63 → 值 1668436.7600000002 BR63 = BQ63/BP63-1 → 值 0.13325484292331224 ` 與列 4 的 B4=1472252.0449999999、C4=1668436.7600000002、F4=0.13325484292331224 逐位元組完全相等（BP63 把 USD 基金〔列 3–51〕直接加總，TWD 基金〔列 52–58〕先乘上 U63匯率折成 USD 再加總）。也就是說：每次結算時分析師先在基金排行表更新完各檔 基金的「投資本金/參考市值」，讓 BP63/BQ63` 自動算出當下總額，然後把這兩個數字 手動複製貼值成日誌的新一列（同時把舊資料整列往下推），D/E/F 才是真正的公式。 只有目前「最上面那一列」（此刻是列 4）會與 BP63/BQ63 相等，一旦下次結算，列 4 會被推到列 5、內容凍結，新的列 4 才會再對上當時的 BP63/BQ63。

完整範例（列 4／列 5，可覆核）：

``` A4=2026-04-14 B4=1472252.045 C4=1668436.76 A5=2026-04-09 B5=1303210.602 C5=1439484.819

D5 = C5-C6-(B5-B6) = 1439484.819-1497148.237-(1303210.602-1318623.12) = -57663.418 - (-15412.518) = -42250.900 （表中快取值 -42250.8998，一致） E5 = C5-B5 = 1439484.819-1303210.602 = 136274.217 F5 = C5/B5-1 = 1439484.819/1303210.602-1 = 0.1045680697 ```

列 53 的 *6/7 手動調整（已重算驗證，成因為推測）：

``` r53: A=2024-05-31 B=174447.16 C=187826.6312 r54: A=2024-05-10 B=172302.16 C=182747.3034 （相隔 21 天）

D53 = C53-C54-(B53-B54)*6/7 = (187826.6312-182747.3034) - (174447.16-172302.16)*6/7 = 5079.3278 - 2145*0.857142857 = 5079.3278 - 1838.5714 = 3240.7564 （表中快取值 3240.756371，一致） `` 6/7 恰等於 18/21——21 天正好是這一段罕見的長間隔（多數列間隔 4–47 天，中位數約 12 天）。若這 21 天中有一筆新增本金（B53-B54=2145）是在第 3 天才真正入帳，剩下的 18/21 天才算「有本金在市場上承擔損益」，用 18/21=6/7 去打折這筆新增本金對「期間 獲利」的稀釋，數學上完全吻合。但這只是根據數字反推的合理猜測，找不到任何儲存格 註解或 comments2.xml 裡的說明能證實；而且同一張日誌裡列 30→31 也有相同的 21 天 間隔（A30=2025-03-23, A31=2025-03-02），卻完全沒有套用類似調整（該區間 B 從 673,063.93 驟降到 39,550，是大額贖回而非新增本金，情境不同）。因此可以確定 *6/7` 是針對列 53 那一次特定注資時間點的一次性手動修正，不是系統化規則，工程 團隊若要重建這段歷史，這筆調整建議直接當「歷史資料修正值」寫死，而不要嘗試推導 成通用公式。

4. 段二：列 81–538（A–H + I/J/K/L/N，TWD，由新到舊）

表頭與標籤（列 76–79，逐儲存格核實）：

逐欄定義（A–H）：

重要：B/C 欄位在段一與段二的意義互換——段一 B=投資本金(成本)、C=參考市值； 段二 B=總參考市值、C=庫存成本(成本)。同一組欄位字母在兩段代表相反的量，這是 移植成程式時最容易踩到的陷阱。段一 E（累積獲利=C-B=市值-成本）在概念上對應 段二 D（未實現損益=B-C=市值-成本），只是欄位互換。段一 D（期間獲利，市值變化 減本金變化）在概念上對應段二 G（當日淨損益）。

完整範例（列 82／列 83，可覆核）：

``` A82=2026-04-24 B82=60012037 C82=49895142 A83=2026-04-23 B83=58842166 C83=48737730

D82 = B82-C82 = 60012037-49895142 = 10116895 E82 = D82/C82 = 10116895/49895142 = 0.2027631267 G82 = (B82-B83)-(C82-C83) = (60012037-58842166)-(49895142-48737730) = 1169871 - 1157412 = 12459 H82 = G82/C82 = 12459/49895142 = 0.0002497036685 ``` （以上四個值皆與工作表快取值 D82=10116895、E82=0.20276312671882965、 G82=12459、H82=2.4970366854552693E-4 完全吻合。）

4.1 I 欄「帳戶預估淨損益」——只有兩列是真公式，其餘是手動貼值，而且只追蹤了一段時間

• I77＝=贖回損益!N10（帳戶預估總報酬率）、I78＝=贖回損益!L10（帳戶預估淨損益），

這是唯二的公式。

• 從 I83（2026-04-23，值 14,692,945.81，正好等於 I78）開始往下，一路到 I304

（2025-08-09，值 1,200,538.06），共 222 列全部是純數字（覆核 XML 皆無 <f> 標籤）， 逐列滿足 I[r]-I[r+1]=G[r]（例：I83-I84=260824=G83、I84-I85=434615=G84）， 代表這其實是一條「每日淨損益累加」的移動總和，但整條鏈是人工每天手貼，不是活公式。

• I305 之後（更早的資料，2025-08-08 以前）完全沒有 I 值，代表這個「帳戶預估淨損益

逐日追蹤」功能是後來才開始維護，只回補到 2025-08-09，再往前（到最舊的 2024-08-28） 就沒有這條數列了。

• 這個 I 欄斷點（列 304/305）恰好也是 J 欄月彙總公式換算法的分界線（見 4.2）。
• 條件格式 I79:I538 有 top10 與 =MAX($I$79:$I$538) 規則，代表這欄原本是設計給

圖表/最大值標記用的，但因為下半部（305 列以後）完全空白，這些條件格式對舊資料 沒有作用。

4.2 J/K/L 月彙總——只出現在約 16 個「月結」列，公式方法在某個時間點切換過

J/K/L 只在以下 16 列出現（大致每月一筆，由新到舊）：94, 119, 142, 168, 193, 218, 247, 275, 302, 333, 363, 392, 415, 442, 467, 486。

例：J275: =I278-I304（304 正好是 I 欄最後一列！）→ J302: =SUM(G305:G335) （改成 SUM(G)）。這證實：J 欄「月獲利」公式的計算方法在 I 欄資料斷點（列 304/305） 處自動切換——凡是月份區間落在 I 欄有資料的範圍內（2025-08-09 之後），就用 I 欄 頭尾相減；月份區間更早、I 欄沒資料，就退回用 G 欄（每日淨損益）直接加總。這不是 巧合，而是分析師因應資料缺口做的權宜設計。

實際數值範例（列 94，2026-04-09 這個月結點）： `` J94 = I94-I119 = 8795234.392-4803129.025 = 3992105.367 K94 = AVERAGE(C94:C118) = 39728154.56 L94 = J94/K94 = 3992105.367/39728154.56 = 0.1004855476 ``

列 80–95 的 N/R/S/T 鏡像小表（與月彙總同資料，但發現一筆數字對不上）

列 80–95 的 N（期間）、R（月獲利）、S（月平均成本）、T（月獲利率）四欄，是 把上面 16 個月結列的 J/K/L 重新排成一張連續、緊鄰表頭的小表（可能是給圖表用的資料 來源，因為原始的 J/K/L 散落在 458 列的日誌裡、間隔不固定，不利畫圖）。逐列核對 16 組資料，15 組完全吻合，唯獨 1 組不吻合：

其餘 14 組差異全部是 0。第 85 列的 R85 與 S85／T85 一樣是純數字（無公式）， S85（月平均成本）與 K218 完全相等（30,503,764.517241381），只有 R85（月獲利） 與 J218 相差整數 104,359（小數部分 .91041854862 一字不差），代表：這張鏡像小表 是某個時間點的一次性貼值快照，之後 I 欄或原始日誌若因追溯調整（例如補登一筆 回溯認列的贖回損益）而變動，J218 這個活公式會自動反映最新結果，但已經貼死的 R85 不會跟著變，於是兩邊出現落差。若前端／報表有任何地方是直接讀這張 N/R/S/T 小表而非重新用 J/K/L 公式邏輯計算，該月（2025-10-08~2025-11-07）的月獲利會少 104,359 元台幣。

4.3 列 80／81：段二最上方的「銜接列」，其中列 81 有公式指向錯誤

• 列 80：只有 A80=46135（2026-04-23，序列值，純數字非公式）與 D80=10104436

（純數字，等於 D83 的值）。B/C/E/F/G/H 全部空白。此列本身不是完整的每日紀錄， 而是專門餵給「贖回損益」表的錨點：贖回損益!K2 = 個股要點!A80（結算日期）， 贖回損益!N6 = 個股要點!D80（浮動盈虧台幣），兩者皆已用原始 XML 核實。

• 列 81：A81/B81/C81 全部空白；D81 = B81-C81 = 0（公式，但因為 B/C 皆空所以

結果恆為 0）；E81 = D81/C81 = #DIV/0!；G81 的公式是 =(B81-B100)-(C81-C100)——注意分母/減項跳過了正常的「往下一列」（B82）， 直接跳到 19 列之後的 B100/C100，這與其餘 456 列一致採用「=(B[r]-B[r+1])-(C[r]-C[r+1])」 的模式明顯不同；H81 = G81/C81 = #DIV/0!（因 C81 空白）。這看起來是「今日待填」 的佔位列，但 G81 的公式參照範圍是錯的（很可能是插入新列時忘記把公式從舊的 「往下 19 列」調整回「往下 1 列」），目前仍是活的、會算出一個數字（-855,883）但 語意上不代表任何真實的期間損益，工程團隊重建這段邏輯時不要照抄列 81 的 G 公式 模式。

• 真正第一筆「完整」的每日紀錄是列 82（2026-04-24），比段一（列 4，2026-04-14）

的最新日期還新 10 天。

4.4 列 538：段二最舊列的邊界異常

G538 公式是 =B538-B539，但 B539 是空白（=0，因為列 538 已是日誌最後一列）， 所以 G538 直接等於 B538 本身（12,573,057），並非真正的「當日淨損益」；連帶 H538 = G538/C538 = 12573057/11777013 = 1.067593031，也就是把「當日報酬率」算成了 106.76%，明顯是公式在資料邊界失真、不是真實數字。段一遇到同樣的邊界問題 （列 69 沒有更舊列可比）處理方式不同——直接把 D69 留空，不讓公式硬算出離譜的 值；段二則是任由公式跑出 106.76% 這種異常值。工程團隊在重建歷史序列時，最舊一 筆的期間損益/報酬率都應該視為「無效」而非計算結果。

4.5 F 欄硬編碼贖回損益換算公式（已完整驗證）

段二的 F 欄（已實現台幣損益）在 458 列裡只有 10 列有值，全部集中在日誌最舊 的一段（2024-08-28～2025-02-09，也就是最靠近列 538 的區間），2025-02-09 以後 （列 80–465，涵蓋 2025-02-10～2026-04-24 共 14 個月）完全沒有再出現這種手算欄位。 每一筆都是「把當期多筆贖回的美金已實現損益手動加總，再除以 $U$63（美金兌台幣 匯率，值 0.0315，即「1 台幣＝0.0315 美元」，T63 標籤寫「美金/台幣=」）折算成台幣」。

已用程式重算全部 10 筆，與工作表快取值完全一致：

``` F466（2025-02-09）： =(470.78-82.36-41.62-52.11-3607.91-11.23-519.37+167.38+166.4-18.78)/$U$63 = (-3547.82) / 0.0315 = -112,026.0317 （快取值 -112026.0317，一致）

F485（2025-01-16）： =(3209.12+27.37-237.26-515.3-508.84-2320.07-617.14-598.86-60.95-62.88-55.7-66.63)/$U$63 = (-1806.14) / 0.0315 = -57,369.5238 （快取值 -57369.52381，一致） `` 其餘 8 筆（F495、F499、F502、F503、F504、F511、F528、F538）也逐一代入 U63=0.0315 重算，全數與快取值相符，其中 F528、F538 還額外加上/減去整數常數 （F528 = (-290.13+60.15)/$U$63+147908-6209；F538 = (...)/$U$63-25662+13920`）， 研判是把「美金贖回損益」與另一筆「台幣本位的贖回損益」加總在一起。

F79 = SUM(F80:F538) = 145,147.1587301587，用程式把這 10 筆快取值精確加總（以 Fraction 精算，非浮點近似）同樣得到 145,147.1587301587，與 F79 完全相符，確認 F79 就是這 10 筆手算換算的總和，沒有涵蓋 2025-02-09 之後任何一筆贖回——如果 2025 年 2 月之後帳戶仍有贖回交易（幾乎可以肯定有，因為「贖回損益」表本身的交易 明細有 260+ 筆一路延續到近期），那麼這個 F79 只是「早期一段時間、用另一套土法算 的補充小計」，不能當作帳戶全部已實現損益的權威數字，權威數字應該是「贖回損益」 表的 M6（累計台幣已實現損益）。

還有一個值得注意的重要事實：$U$63 是單一儲存格、全表共用的「目前」匯率 （U62=46126=2026-04-14，U63=0.0315），這 10 筆公式橫跨 2024-08 到 2025-02 共 半年的歷史資料，全部用同一個「現在」的匯率去折算，而不是各自贖回當天的實際匯率。 也就是說，這些歷史台幣金額會隨著 U63 每次更新而整批跟著變動，並非固定的歷史 換算結果。若要在系統裡重建這段邏輯，需要決定要不要保留這個「用今日匯率回溯換算 所有歷史贖回」的行為，或改成用交易當天的真實匯率。

5. 與「贖回損益」表的循環參照鏈（已用原始 XML 雙向驗證）

「個股要點」的段二儀表板（列 76–80）與「贖回損益」的「帳戶彙總區」（K2:N10） 彼此互相讀取，形成一個完整迴圈：

``` 個股要點!A80（結算日期，手動值）───→ 贖回損益!K2 (=個股要點!A80) 個股要點!D80（未實現損益，手動值）─→ 贖回損益!N6 (=個股要點!D80) 個股要點!C78（庫存成本，手動值）───→ 贖回損益!L9 (=個股要點!C78)

贖回損益 內部： L4/M4 = 16 段不連續列範圍的台幣 SUM（贖回明細表） L5/M5 = 17 段不連續列範圍的美金 SUM L6 = L4 + L5/個股要點!U63 （美金部分用個股要點的匯率折台幣） M6 = M4 + M5/個股要點!U63 L8 = L6-M6 ... N8 = M6/L8 L9 = 個股要點!C78 ← 上面已提到 N9 = N6/L9 L10 = M6+N6 （已實現+未實現） N10 = L10/L9

贖回損益!L10（帳戶預估淨損益）───→ 個股要點!I78 (=贖回損益!L10) 贖回損益!N10（帳戶預估總報酬率）─→ 個股要點!I77 (=贖回損益!N10) ```

（每一條都已用 <f> 原始 XML 覆核，數值鏈：K2=46135、N6=10104436、L9=48737730、 L6=93377097.857142851、M6=4588509.8095238088、L10=14692945.80952381、 N10=0.30146963778419328，與 I78/I77 的快取值完全一致。註：L8 的公式是 「累計台幣交易額(L6) 減 累計台幣損益(M6)」＝累計贖回成本，不是 L6-L4。）

也就是說，個股要點的 C78/A80/D80（全是手動貼值）是「贖回損益」表計算鏈的輸入， 而「贖回損益」算出的結果又回頭餵給個股要點的 I77/I78。這代表移植這段邏輯到系統 時，「個股要點」段二儀表板不是一個可以獨立運算的模組，必須同時把「贖回損益」表 K2:N10 這一段（尤其是它自己那 16+17 段手動維護的硬編碼列範圍 SUM，docs/excel/03-贖回損益.md 已指出這是「Excel 流程中最脆弱的一環」）一起納入。另外還發現：B78/C78 實際上是複製自列 83（2026-04-23）而不是段二真正最新的列 82（2026-04-24）， 代表這條循環鏈使用的「目前庫存成本」永遠會比日誌實際最新資料晚一天，是一個 小幅但確實存在的滯後。

6. 兩段的日期範圍與先後關係（修正原先的假設）

實際查證的日期範圍如下（Excel 序列日期換算為西元日期）：

這與題目給的「列81-538是較早期/舊版、列4-69是後來簡化過的格式」需要修正一下： 若以「資料本身最早追溯到哪一天」來看，段一（USD，最早到 2023-12-24）比段二 （TWD，最早只到 2024-08-28）早了 8 個多月；但若以「最後一次更新是哪一天」來 看，段二（2026-04-24）比段一（2026-04-14）還要新 10 天，代表段二至今仍在被逐日 維護，段一則是每次結算才動一次。兩段真正重疊、同時被維護的期間長達約 20 個月 （2024-08-28～2026-04-14）。所以比較準確的描述是：帳戶從 2023 年底開始只用段一 這種「每次結算貼一列 USD 總額」的簡單方式記錄；2024 年 8 月下旬（列 70 的更新 註記「2024/08/16 03:21」與段二最舊列 2024-08-28 幾乎同時，很可能是這個時間點開始 建置段二）新增了一套更精細的「逐日 TWD 淨值追蹤」機制（段二），此後兩套機制 並行維護至今——不是「舊格式在某個交接點被新格式取代」，而是「兩條並行的歷史 線，分別服務不同目的（USD 資本額變化 vs. TWD 逐日損益）」。用當前最新一列做量級 交叉驗證也支持這個結論：段一列4（2026-04-14）的 C4=1,668,436.76 USD，換算 1668436.76/0.0315≈52,966,246 TWD；段二列82（2026-04-24，晚10天）的 B82= 60,012,037 TWD——量級一致（同屬千萬等級台幣總市值），差額可用 10 天的市場波動 與資金進出解釋，佐證兩段確實在追蹤同一個帳戶。

7. 給工程團隊的重點提醒（彙整）

1. B/C 欄位語意在兩段相反：段一 B=成本(USD)、C=市值(USD)；段二 B=市值(TWD)、

C=成本(TWD)。逐字對照移植會算反正負號。

1. 段一 B/C 不是公式，是「基金排行表」BP63/BQ63（USD 加權總額）的貼值快照；

只有目前最上面一列會與 BP63/BQ63 相等。

1. 段一列 53 的 D53 有一次性 *6/7 手動調整，數學上等於「新增本金只被 21 天中的

18 天承擔損益」，但只出現這一次，不是通用規則，且無任何儲存格註解佐證原因 （已排除同樣 21 天間隔的列 30/31 也套用同一調整）。

1. 段二 F 欄（已實現台幣損益）只在 10 列（2024-08-28～2025-02-09）出現硬編碼

「多筆美金贖回損益加總 ÷ $U$63」公式，2025-02 之後完全沒有再更新，F79 的 總和 145,147.16 台幣不是帳戶全部已實現損益，只是這一小段時間的補充小計。 且全部 10 筆都用「目前」匯率 U63=0.0315 回溯換算，不是交易當天匯率。

1. 段二 I 欄（帳戶預估淨損益逐日累計）只有 I77/I78 是真公式，I83–I304（222 列）

是每日手貼的數字，I305 以後（更早的資料）完全沒有維護，這個斷點同時也是 J 欄（月獲利）公式方法從「I 欄相減」切換成「G 欄加總」的分界。

1. 列 80–95 的 N/R/S/T 月彙總鏡像小表與下方真正的 J/K/L 公式，有 1 組（2025-10-08~

2025-11-07 期間，鏡像列85 vs. 公式列218）對不上，差 104,359 元台幣，證實這張 小表是舊快照、不會隨後續資料修正自動更新。

1. 列 81 的 G81 公式誤指向「往下 19 列」（B100/C100）而非其餘 456 列都採用的

「往下 1 列」，是一個活著但語意錯誤的公式；列 538（最舊列）的 G538/H538 因為 沒有更舊列可比，算出 H538=106.76% 這種不合理的「當日報酬率」——兩種邊界 情況段一都選擇留空，段二則讓公式跑出失真值，重建時建議統一以「無效/N/A」 處理最舊一筆的期間損益。

1. 「個股要點」段二儀表板（C78/A80/D80 → I77/I78）與「贖回損益」的

K2/L9/N6 → L10/N10 形成雙向循環參照，兩表必須一起搬遷，且「贖回損益」自己 的 L4/L5/M4/M5 是 16+17 段不連續列的硬編碼 SUM（docs/excel/03-贖回損益.md 已指出是最脆弱環節），會直接影響回灌到本區塊 I77/I78 的數字；其中 L8=L6-M6 （累計贖回成本＝累計贖回交易額－累計贖回損益），移植時要對齊這個算法，不要 誤植成其他兩個儲存格相減。

1. C78/B78 實際貼自段二列 83（2026-04-23）而非當時最新的列 82（2026-04-24），

循環鏈使用的成本基準會比日誌最新資料晚一天。

1. 列 70–77 之間（全部基金/2024/08/16 03:21更新、代號 jsmart88、申購贖回狀態

備忘、列 77 的「=B47-C47」等文字）屬於備忘/過渡資料，不是日誌的一部分；其中 列 77 的三個儲存格（D77/E77/G77）是純文字字串（Excel 儲存格型態 t="s"）， 看起來像公式但不會被求值，不要誤判成真的參照到列 47/48。

查無資料的部分：F466/F485 等硬編碼公式裡每一筆個別小數字（如 470.78、82.36…） 對應到「贖回損益」表哪幾筆交易列號，因為這些數字是直接寫死在公式裡（沒有引用 儲存格），單靠「個股要點」本身的資料無法逆推出對應列號，需要人工比對「贖回損益」 明細表的 F/G 欄（交易金額/參考損益）金額才能還原，本次查證未做逐筆金額比對。

右側決策備忘區、下拉字彙與金字塔額度法（個股要點工作表）

區塊定位與用途

這個區塊落在「個股要點」556×103 表格的最右側（欄 CG～CU，部分延伸到 CV/CW/CY），實際內容涵蓋四個彼此獨立、互不以公式串接的子區塊：①R1 列的排序/篩選工作流提示（P/R/S/T 欄的短標籤 + AA:BF 欄的「#N」殘留編號）；②CG13:CL18 的「斜率代碼→對策」決策速查表；③CP/CQ 的下拉字彙來源區；④CR:CU（含延伸的 CV/CW/CY）的「金字塔投資額度法」配額試算表。逐一核實後最重要的發現是：這整塊幾乎全部是純文字/純數字的靜態備忘資料，只有極少數儲存格帶公式——它是分析師人工決策時的「小抄」與草稿試算區，而不是驅動表格其他欄位的計算引擎；真正把「對策」寫回主表（BU/BE 欄）的，其實是另一條路徑：每檔基金各自工作表上的手動下拉選單（詳見下方「與其他工作表的引用關係」）。

1. R1 列的排序/篩選工作流提示（P/R/S/T 欄）

實際查證 R1 列内容（d.display(1,'P'..'T',ss)）：

查證結論：R1 這四個標籤不是對應欄位本身的資料說明，而是「工作流程提示卡」——提示分析師依序做 4 次人工排序/篩選（1. 用 P 欄排斜率、2. 排完後用 R 欄的基金代碼配合投資建議判斷、3. 用 S 欄篩「低空間」、4. 用某個乖離率篩 >2.5% 的標的）。其中 P、T 兩欄本身完全靠人工輸入整數名次、沒有任何 RANK() 之類的公式；目前快照顯示 P 欄已填好（P3:P58 共 56 格，值為 1~56 連續，對應 56 檔基金），但 Q、T 欄整欄（Q3:Q58、T3:T58）都是空的，表示這一輪分析只做到第一步。這點原始摘要沒提到，是本次查證新增的重要細節：這些排名欄不是自動排序結果，是純手動填入的名次。

逐位元組核對前導空白（更正原摘要的一處錯誤）：用 d.display(1,col,ss) 取出每個字元的碼位後發現，P1、R1、S1 三格標籤前面都各自帶一個半形空白（U+0020，不是全形空白）——即 ' 1.斜率'、' 2.投資建議'、' 3.低空間'；只有 T1（'4.>2.5%'）前面沒有任何空白。這與「S1、T1 前面都沒有多餘空白」的說法不符：S1 其實跟 P1、R1 一樣有前導空白，四欄裡真正「沒有空白」的只有 T1 一個。已用 tools/out/基富投資1/個股要點.txt 的 R1 dump（S= 3.低空間，等號後面就是一個空格）交叉核實無誤。

2. AA:AN、AT:BG 的「#N」編號殘留標籤

已知事實描述的跳號現象已用 d.display(1, col, ss) 逐欄核實，完整對照如下：

第一組（AA:AN，13 個指標欄 + 1 個無編號欄）

第二組（AT:BG，12 個帶編號欄 + 1 個文字欄 + 1 個文字欄）

關於「#N」編號圖例的查證結果：用 Grep 搜尋 tools/out/基富投資1/ 下所有 .txt（含 _OVERVIEW.txt、各基金分頁、TW50_OBV圖例.txt），只有「個股要點.txt」本身的 R1 那一行含有 #1…#13 字樣；TW50_OBV圖例.txt 的「圖例」是 Yahoo Finance 0050.TW 股價圖表的 K 線圖例（OBV/MA20/MA50 折線圖），與此編號完全無關。原始檔案中查無任何對應的「#1～#13 代表什麼」的圖例文字說明。

但額外查證發現一條有價值的旁證：舊版工作簿 data/基金五線譜建資料庫5-20-50宏.xlsm（抽取檔 tools/out/基金五線譜宏/個股要點.txt）裡也有同一張「個股要點」表，其 R1 列同樣出現 P=#1 | Q=#2 | R=#3 | T=#4最近<4年資料 | U=#5 | V=#6 | W=#13 | X=#7 | Y=#8 | Z=#9 | AA=#10 | AB=#11 | AC=#12——跳號位置與模式（"...#6 之後直接跳到 #13，再回頭接 #7...#12"）與現行版完全一致，只是欄位字母因為後續插入新欄而整體右移了（P→AA、W→AH…）。這證實了：

• 這不是隨機打字錯誤，而是「#13」這個項目本來就被刻意排在「#6」和「#7」中間的欄位位置上，且此排列從舊版一路沿用到新版；
• 第二組（AT:BG）少了「#2」（被 AU 的說明文字取代）也是類似性質——原本該是「#2」標籤的儲存格，被作者拿來寫一段對 AU 欄（現價與最高價的差比）的操作提示文字，因此犧牲了編號的連續性；不過要注意，舊版工作簿裡對應這個位置的另一組編號（AI:AU，13 欄）其實是 #1~#13 完全連續、沒有跳號，所以「AU 被文字取代」這個特定安排看起來是新版才出現的變化，並非直接沿用舊版，僅供工程團隊留意，不宜過度推論。
• AC/AF/AG/AH（Div/P、单位净值、单位成本、总成本）以及 AT/AV（每次可投資、可投資額度）合計 6 個「有編號、有正式表頭」的欄位，在全表 56 列基金資料中完全沒有填值，也沒有公式 ——是已規劃但從未啟用的欄位。AW:BD 這 8 欄則連表頭都沒有，只剩 R1 的編號殘影（已逐列核實整張 556 列表格中，這 8 欄真的都只剩這 1 格有值）。這是本次查證找到、原摘要未提及的具體「殘留欄位」清單，工程團隊若要 1:1 重建此表，這些欄位應視為「保留但目前無資料」，不必費工去猜測其計算邏輯。

3. 經營對策流程（CG 欄，三步驟文字）與 CG13:CL18 決策速查表

CG2:CG5（純文字，CG 整欄查證下來沒有任何公式）：

新發現、原摘要未提到的內容：CG13 往下到 CL18 是一張完整的「斜率代碼 → 對策動作」速查表，且有 12 個合併儲存格（CH13:CJ13、CH14:CJ14…CH27:CJ27）撐開文字區塊；其中 CH21（值「觀望」）、CH26（值「2/3贖回」）雖然有文字內容，卻沒有被合併；CH24 則既沒有合併也沒有值——因為第 24 列（CG24、CH24）本身就是一整列空白（格式間距列），這與下表第 24 列標註「空白列」是一致的：

這張表把三種市場階段（多頭／不明盤整／空頭）各自搭配 4 種「代碼樣式」對應到 7 種對策文字（加強增購／增購／1/2增購／觀望／1/3贖回／2/3贖回／5/6加強贖回），並用 CL14:CL18 說明代碼裡 0/1/2/3 分別代表市價線／短期均線／中期均線／長期均線，+/- 代表正負值。查證：CG13:CL18 這整塊沒有任何公式指向或被指向（d.formulas 對 CG/CH/CL 欄查詢皆為空），也沒有其他工作表引用這個範圍——它是純粹給人看的「對照卡」，不是自動判斷邏輯，這一點原摘要沒有提及，是本區塊除金字塔額度法外最重要的新發現。

它與 AL/BO 欄「市場現狀」字串（如 多-橫向整理[201]、多頭排列[012]）用的 0/1/2 排列括號是同一套記號體系概念上的延伸，但沒有實際公式串接——AL 是直接從各基金分頁拉入的字串（如 AL3=柏瑞印度!BX6），BO 則是鏡射 AL 欄本身（BO3=AL3，跟 BE 欄鏡射 BU 是同一種手法，shared formula 涵蓋 BO3:BO34），兩者都不會反查 CG13:CL18。

4. 下拉字彙來源區（CP 幣別、CQ 對策）

實際逐格查證 d.display：

CP/CQ 整欄同樣完全沒有公式——純文字清單。

重要澄清（原摘要容易讓人誤會的地方）：CQ3:CQ8 這 6 格在列號上剛好落在整張基金表的第 3～8 列（即前 6 檔基金：柏瑞印度、柏瑞歐洲、柏瑞環重股、JPM美國科技、JPM歐洲動力、摩根歐洲），因此在原始檔案 R3:R8 header dump 裡會同時看到「CQ=加強贖回」「CQ=贖回」…這 6 個值恰好對齊這 6 檔基金那幾列。這只是空間座標上的巧合，CQ 欄和 R 欄（基金代碼）之間沒有任何公式關聯、CQ 也不是這 6 檔基金的「對策」欄——真正對應到某一檔基金「對策」的欄位是 BU（見下節）。工程團隊重建資料庫時，CQ3:CQ8 應理解為「一份與列位置無關、純粹借用空間放置的詞彙表」，不要誤植為 fund_id ↔ 對策 的對照表。

CP/CQ 的實際下拉選單掛勾情況（用資料驗證核實）：

• Excel 資料驗證清單只有兩筆（## 資料驗證 (2)）：

1. BM70 BJ70:BK70 BK2 BM2 → type=list, formula1=$CN$3:$CN$8
2. V136:V1048576 X1:X71 → type=list, formula1=$CP$3:$CP$5，選單值 = ['美金', '台幣']

• 第 2 筆才是真正把 CP3:CP5（美金/台幣）接到欄位上的驗證，套用範圍是 X 欄（幣別，X1:X71，涵蓋整個 56 檔基金列），以及一段延伸到 V136 以下（超出基金表範圍，屬於複製格式時誤延伸的殘留區）。
• 第 1 筆（BM70、BJ70:BK70、BK2、BM2 的下拉選單）來源是 $CN$3:$CN$8，但直接查證 CN3:CN8 這 6 個儲存格全部是空白（既無值也無公式）。這與已知事實裡「選單值=[美金,台幣]」的敘述不符——那個 [美金,台幣] 其實是第 2 筆驗證（來源 CP3:CP5）的選單值，被誤植到第 1 筆身上。查證結論：BM70/BJ70:BK70/BK2/BM2 這組下拉選單目前來源範圍是空的，等於是一個失效/斷頭的驗證規則，選單彈出時不會有任何選項可選。BK2、BM2 剛好是欄位標頭儲存格（BK2=10EMA20、BM2=10EMA120），推測這條驗證規則是複製格式時誤帶到標頭列，並非刻意設計。
• CQ 的 6 個對策詞彙沒有被任何資料驗證引用（在整個 基富投資1 抽取結果中搜尋 CQ$3、CQ$8 皆無其他儲存格引用），也就是說 CQ 這份詞彙表目前在 Excel 裡完全是靜態展示用，沒有掛在任何實際輸入欄位上。（註：各基金自己工作表內部另有各自本地的 $CQ$4:$CQ$6／$CQ$4:$CQ$8 資料驗證來源，但那是每檔基金分頁「自己工作表內」的同欄位參照，跟「個股要點」的 CQ 欄是完全不同的儲存格，兩者只是欄名字母恰好相同，沒有任何跨表關聯，已用 Grep 逐一排除誤判可能。）

與跨表對策欄的關聯（重要，原摘要未提）：個股要點!BU 欄（R2 標頭「對策」）的公式是逐列拉取各基金自己工作表的 BX8 儲存格，例如 BU3 = 柏瑞印度!BX8。查證柏瑞印度分頁發現：BX8 本身不是公式，而是一個資料驗證下拉格，來源 $CS$4:$CS$11，選單值為 ['5/6加強贖回', '2/3贖回', '1/3 贖回', '觀望', '加強增購', '增購+加強關注', '1/2 增購']（CS4:CS10 共 7 格有值，CS11 本身是空的，屬於驗證範圍多留一格的常見寫法）——這是分析師在每一檔基金自己的工作表上手動選定的對策，再被個股要點!BU 欄拉回來彙總，BE 欄（=BU3）再鏡射一份。也就是說：個股要點的 CQ3:CQ8（6 個詞）是一份精簡版對策詞彙的靜態說明，真正用來輸入的下拉選單（7 個詞、帶分數）在各基金自己的工作表上，兩份詞彙表用字不完全一致（CQ 多了「轉換」，基金分頁的清單沒有「轉換」但多了「增購+加強關注」的複合選項），值得工程團隊注意，統一資料庫的「對策」列舉值時要以基金分頁 CS4:CS11 這份 7 項清單為準，而非個股要點的 CQ3:CQ8。

5. 金字塔投資額度法（CR:CU，並延伸到 CV/CW/CY）

核心配額表（CR2:CU7），逐格核實公式：

CS 欄本身（X、Y、X*0.9/Y*1.2、Z、X-Z）都是純文字說明，不是真正驅動計算的公式；真正的公式全部寫在 CT 欄（CT3、CT5、CT6、CT7 四格皆有 <f>，只有 CT4 是純數字）。CT5 的公式化簡後等於 CT3 * 1.08 / CT4（因為 0.9×1.2=1.08），也就是「帳戶總值打 9 折、除以預設基金檔數、再乘 1.2 倍寬放係數」，20 檔基金若全部用滿額度合計會等於帳戶總值的 108%（刻意留了 8% 的超額配置空間）。

延伸區塊（CR9 / CS9，原摘要未提）：

空間分級表（CR11:CU16，完整的「金字塔」六層額度，原摘要完全沒提到，是本次查證最大的新發現）：

這正是「金字塔投資額度法」名稱的由來：股價/淨值離高點越遠（層級數字越小、越接近「第1空間」＝最深的修正區），每次投入比例門檻越高（10%以上）、累計可投入比例上限也越高（可達 100%）；反之接近高點（第6空間）則每次只准投入 1%以上、累計最多 30%。

CV/CW/CY：把百分比換算成金額的小算式（原摘要未提，且發現這段目前是失效狀態）：

• CV10/CW10 標頭為 每次可投資 / 最高市值；CV11:CV16、CW11:CW16 目前顯示值全部是 0。
• 公式核實：CV11 = $CY$9*LEFT(CT11,2)（即 CY9 * "1%"，Excel 會把文字 "1%" 隱式轉成 0.01 再相乘）；CW11 = $CY$9*LEFT(CU11,3)（CY9 * "30%"）；第 16 列因為門檻是三位數/四位數字串所以改用 LEFT(…,3) / LEFT(…,4)。
• 直接查證 CY9 儲存格：完全空白，既無值也無公式。因此 CV11:CV16、CW11:CW16 這 12 個「把配額百分比換算成實際金額」的公式，現在全部算出 0——這是一個具體、可覆核的公式斷鏈：CY9 應該要接到 CS9（或 CT5，兩者其實同值 78,128.84484）才有意義，但實際上沒有接上，導致這個換算小工具目前形同虛設。工程團隊重建時要注意這一點——不要照抄「CY9 恆為 0」的行為，應該理解成這裡漏了一條 CY9 = CS9 的連結。

帳戶總值/已投資總市值是否為即時資料？（查證，原摘要只是引用交叉文件的說法「沿用 2021 港股時期數值」，本次直接用數字比對加以驗證）

• 個股要點表本身在 BQ63 有一條即時彙總公式：BQ63 = SUM(BQ3:BQ51)+SUM(BQ52:BQ58)*U63，算出的是 56 檔基金目前參考市值加總（USD），查得快取值為 1,668,436.76，與帳戶歷史日誌最新一筆 C4 = 1,668,436.76（對應 A4 = 2026-04-14）完全一致，代表這是即時／最新的組合市值。
• 對照金字塔額度表的 CT6（已投資總市值 Z）= 1,394,990.6，比即時市值少了約 273,446（約 16.4%）。
• 在帳戶歷史日誌裡找最接近 1,394,990.6 的一筆：C9 = 1,393,358.225，對應 A9 = 46035（Excel 序列日期），換算為 2026-01-13（兩者相差約 1,632、僅約 0.1%，是全表最接近的一筆，已對列 4~69 與列 81~538 兩段日誌都做過 1% 容差搜尋，沒有更接近的候選）。
• 查證結論：CT3/CT5/CT6/CT7 這組「金字塔投資額度法」的帳戶總值與已投資市值，是大約 2026 年 1 月中旬的一次性手動輸入快照，沒有隨後續交易或帳戶成長更新，与表格本身即時算出的 4 月數字已經差了 3 個多月、約 16% 的市值成長。這印證了交叉參考文件（docs/excel/02-個股要點-投資組合總表.md）「未隨現帳戶更新」的說法，且本次用具體數字（1,394,990.6 vs 1,668,436.76，相差 273,446）把這個落差量化、並找到了大致對應的輸入日期（約 2026-01-13，並非交叉文件字面所寫的「2021 港股時期」那麼久遠——工程團隊若要引用「多舊」這個說法，建議以本次查到的 2026-01-13 為準）。工程團隊如果要把這個功能做成即時計算，應該讓 CT6（Z＝已投資總市值）直接引用 BQ63（或等價的即時彙總），而不是沿用手動快照數字。

6. 一個完整範例：柏瑞印度股票基金A（第 3 列）的決策鏈

用同一列（row 3）串起本區塊各項資料，展示這套「決策備忘」機制實際如何運作：

1. 基本識別：R3=002008（基金代碼，公式 =柏瑞印度!G3）、S3=F0GBR067HA:FO（Yahoo 代號，公式 =柏瑞印度!I4，不是 I3）、U3=柏瑞印度股票基金A、X3=美金（幣別欄，來自 CP3:CP5 下拉選單，選了「美金」）。
2. 排序名次：P3=1（人工填入，代表這一輪按「5MA5 斜率標準化」排序，本基金排第一名，斜率最陡）。
3. 市場狀態：AL3=多-橫向整理[201]（來自 柏瑞印度 分頁公式拉入），AO3=1（第二套「落區本日」判定＝落在「第1空間」，對照 CR16「第1空間 → 每次投入10%以上，累計可到100%」——處於歷史相對低檔）；AD3=2（第一套「落區本日」判定，屬「第2空間」，同樣偏低檔）。
4. 趨勢與乖離：AA3=0.02660700624（斜率 b，正值＝上升）、BH3=0.00585545411（5MA5斜率標準化，正值）、AU3=-0.1019062339（現價與最高價的差比，現價比最高價低約10.2%，不是 AU1 說的「0 或最小值」，所以此檔並非「優先贖回」候選）。
5. 對策判定：BU3=加強增購，其公式來源是 柏瑞印度!BX8——也就是分析師在柏瑞印度自己的工作表上，用資料驗證下拉選單（來源 柏瑞印度!$CS$4:$CS$11）手動選定的對策，再被個股要點拉回來；BE3==BU3=加強增購（鏡射）。這個結論與 CG14「多頭時，提早分段全額加碼，加強增購」的速查表描述一致（斜率為正、處於低檔空間）。
6. 金字塔額度對照：BQ3（參考市值）=5418.09 USD，相對於 CT5（預計每基金額度）=78,128.84484，只用了約 6.9% 的配額（5418.09 / 78128.84 ≈ 0.0694）。搭配它落在「第1空間」（CR16：每次投入 10%以上、累計上限 100%），意味著理論上這檔基金還有非常大的加碼空間——與 BU3=「加強增購」的結論相互印證。
7. 收益率與市值排名：BR3=-0.0411（收益率 -4.11%）、BS3=0.003247405074（占總市值 0.32%）、BT3=49（市值排名第 49，56 檔中排名偏後，反映目前部位很小，與第 6 點「只用了 6.9% 額度」吻合）。

這條鏈完整串起：識別欄 → 人工排名欄 → 市場狀態/空間分級 → 決策速查表的定性描述 → 各基金分頁手動選定的對策 → 金字塔額度法的配額使用率，可以看到整個「決策備忘區」設計的意圖，是讓分析師在同一張表上，同時看到「規則（CG13:CL18、CR11:CU16）」與「個別基金當下的量化位置（AL/AO/AU/BH…）」，再手動到各基金分頁勾選對策。

7. 給工程團隊的重點提醒（異常/硬編碼/待確認清單）

1. CQ3:CQ8「對策詞彙」與真正驅動 BU/BE 欄的對策詞彙不是同一份清單：個股要點的 CQ 是 6 項精簡詞（加強贖回/贖回/轉換/觀望/加強增購/增購），沒有被任何資料驗證引用；真正生效的下拉清單在各基金分頁的 $CS$4:$CS$11（7 項、含分數，如 5/6加強贖回、增購+加強關注），兩者用字不完全對應（CQ 有「轉換」，基金分頁沒有）。建庫時列舉值請以基金分頁的 7 項為準。
2. BM70/BJ70:BK70/BK2/BM2 這組資料驗證來源 $CN$3:$CN$8 是空的，不是原摘要所寫的「選單值=[美金,台幣]」（那其實是另一筆驗證，來源 $CP$3:$CP$5，套用在 X 欄）。這條驗證目前是斷頭/失效狀態，且套用位置剛好蓋到 BK2、BM2 兩個欄位標頭儲存格（10EMA20、10EMA120），推測是格式複製時誤帶的殘留規則，非刻意設計，重建時可以直接忽略。
3. CV11:CV16、CW11:CW16（把金字塔空間層級的百分比換算成金額）目前全部算出 0，因為引用的 $CY$9 是空白儲存格，未接到 CS9/CT5。若要重現這個「每次可投資金額／最高市值上限金額」換算功能，需要補上 CY9 = CS9（或直接讓公式引用 CS9）這條連結。
4. CT3/CT5/CT6/CT7（帳戶總值、每基金額度、已投資總市值、短期理財額度）是手動輸入的靜態快照，比對表格自身即時彙總的 BQ63（=1,668,436.76，對應 2026-04-14）發現 CT6（1,394,990.6）對應大約 2026-01-13 的舊數字，落後約 3 個半月、市值少算約 16.4%。若要做成「即時金字塔額度」功能，CT6 應改為即時引用 BQ63，CT3/CT7 隨之連動，而不是手動貼數字。
5. AC/AF/AG/AH（Div/P、単位净值、単位成本、总成本）與 AT/AV（每次可投資、可投資額度）共 6 個「有正式表頭」的欄位，56 列基金資料全部空白、也沒有任何公式——是規劃了但從未真正啟用的欄位，重建資料庫時不必勉強對應。
6. AW:BD（共 8 欄）除了 R1 各自留有一個「#4」～「#11」的孤立編號外，全欄（556 列）沒有任何其他內容（表頭、資料、公式皆無），是完全空的殘留欄位。
7. AA:BF / AT:BG 這組「#1」～「#13」編號在個股要點與 docs/excel/ 交叉文件中都查無圖例說明文字；但比對舊版工作簿 基金五線譜建資料庫5-20-50宏.xlsm 裡同名「個股要點」分頁，發現同樣的跳號模式（#6 之後直接接 #13、再回頭接 #7…#12；第一組結構與現行版一致）在新舊版本間吻合，可判定這是舊版遺留、欄位在版本間搬移但未重新編號的殘留標籤，而非隨機輸入錯誤（不過舊版對應第二組的編號其實是 #1~#13 連續無跳號，所以「第二組缺 #2」看起來是新版才出現的變化，並非直接沿用舊版，工程團隊不宜過度推論兩組跳號成因完全相同）。沒有找到任何文字解釋這些編號的業務含義，不建議臆測。
8. CG13:CL18 決策速查表與 CR11:CU16 金字塔空間分級表，彼此之間、以及與 AL/AO/AD 等「市場現狀/落區本日」欄位之間，都沒有實際的 Excel 公式連結——全部要靠人工比對閱讀。若要把這套邏輯系統化（例如自動根據 AO 落區＋AL 市場現狀產出建議對策），需要工程團隊重新把 CG13:CL18 與 CR11:CU16 這兩張「紙上對照表」轉譯成明確的規則引擎，因為 Excel 原始檔裡並沒有這條自動化路徑。
9. CG/CP/CQ/CR/CS/CU 整欄查證下來完全沒有公式（僅 CS9、CT3、CT5、CT6、CT7 及 CV/CW 少數幾格有公式——CT6 雖然公式內容只是字面數字 =1394990.6，但技術上仍是一顆公式儲存格，跟 CT4 那種完全沒有 <f> 標籤的純數字不同），且沒有被 贖回損益.md、其他基金分頁等任何外部工作表引用（用 Grep 對整個 tools/out/基富投資1/ 搜尋 個股要點!$CQ、個股要點!$CG 等寫法皆無結果；另外直接解析 贖回損益 分頁公式，確認它只讀取 個股要點!A80、U63、D80、C78 這 4 個帳戶彙總欄位，方向是「贖回損益 去讀 個股要點」，且完全不碰 CG/CQ 這個決策備忘區）——確認這整塊是自我封閉、單向只被人眼閱讀的備忘/工具區，不是資料流的一部分。

附：資料來源與查證方式

• 逐格數值/公式：直接以 parse_sheet_xml 解析 data/_recovered_基富投資1.xlsx 的 個股要點 工作表 XML，對照 xl/sharedStrings.xml，非透過 dump 檔的截斷/格式化版本（d.display() 回傳完整字串，不像 tools/out/…txt 的表頭 dump 會做 40 字元截斷）。
• 資料驗證、合併儲存格、條件格式：核對 tools/out/基富投資1/個股要點.txt 的「資料驗證 (2)」「合併儲存格 (13)」「條件格式 (15)」區塊，並用 Python 重新解析 XML 交叉驗證選單來源是否真的有值。
• 跨表引用（BU→柏瑞印度!BX8、BX8 的下拉來源 CS4:CS11 等）：解析 柏瑞印度 分頁 XML 的公式與資料驗證區段。
• 「#N」編號圖例查證：對 tools/out/基富投資1/、tools/out/基金五線譜宏/ 全目錄做 Grep，並人工比對兩個版本的「個股要點」R1 列內容。
• 贖回損益引用方向查證：解析 贖回損益 分頁 XML，列出所有含「個股要點」字樣的公式，確認方向為「贖回損益 讀 個股要點」，且未涉及 CG/CQ 決策備忘區。

本次審核的修正摘要（相對於原始草稿）：

1. S1 儲存格其實跟 P1/R1 一樣帶有半形前導空白（' 3.低空間'），原稿誤寫成「S1、T1 都沒有前導空白」；四欄中唯一沒有前導空白的其實只有 T1。
2. S 欄（Yahoo 代號）的跨表公式來源是各基金工作表的 I4，不是原稿寫的 I3（柏瑞印度!I3 存的是星數「4」，I4 才是 Yahoo 代號），此處共修正了 2 處（規則說明表 + 第 6 節範例）。
3. P3:P58 的人工排名值範圍是 1~56（對應 56 檔基金），不是原稿寫的「1~58」——58 只是列號，不是排名值本身，此處共修正了 2 處。
4. CG13:CL18 速查表的合併儲存格footnote：CH24 其實完全空白（第 24 列本身是空白列），不是「未合併但仍有值」；真正「未合併但仍有值」的只有 CH21、CH26 兩格。
5. CT6（已投資總市值 Z）技術上仍是公式儲存格（=1394990.6），不是原稿寫的「純數字，無公式」；已同步更新第 5 節表格與第 7 節清單第 9 點的公式清單。
6. AL/BO 欄的關係澄清：AL 是直接從基金分頁拉入的公式，BO 其實是鏡射 AL 欄本身（BO3=AL3），不是「AL/BO 都直接以公式拉進個股要點」。
7. 補充查證了贖回損益分頁的實際引用公式，確認方向是「贖回損益 讀 個股要點」且不涉及本區塊（CG/CQ），呼應原稿第 7 節第 9 點的說法。

以上 6 類問題均已直接於本文中修正，其餘內容（CR:CU 金字塔配額表數值、CR11:CU16 空間分級表、資料驗證兩筆、CQ/CS 對策詞彙清單、CY9 斷鏈、帳戶快照日期比對等）逐格核實後與原稿一致，未發現其他錯誤。

區塊角色與定位

「個股要點」列 3–58（共 56 列）是整本活頁簿的「投資組合主控台」：每一列代表一檔基金，橫向串接約 30 個跨表公式，把該基金在自己五線譜工作表（如「柏瑞印度」）裡算好的統計量（星等、類別、全歷史/900日斜率與標準差、位階、乖離率、對策…）「拉」進總表，再加上兩組事先設計好的排序權重欄（AA–AN 對應「優先贖回」#1–#13、AT–BF 對應「加碼考量順序」#1–#13，標籤見 R1 列），供使用者在一張表上比較 56 檔基金、決定加碼/贖回。這個區塊也透過 I77/I78 與「贖回損益」工作表做雙向串接，把已實現贖回損益＋未實現浮動損益合併成「帳戶預估總報酬率」顯示在總表上。

重要架構事實：這 56 列 × 33 欄不是用 INDEX/MATCH 或具名範圍做的通用查表，而是每一列手刻一組固定寫死目標工作表名稱的公式（例如列3固定寫 =柏瑞印度!G3，列4固定寫 =柏瑞歐洲!G3…）。新增/刪除基金、或调整列序時，必須整列手動重寫全部跨表公式，沒有任何自動化機制——這是移植成資料庫系統時必須改掉的核心痛點。

逐欄位對照表（以列 3＝柏瑞印度為例，全部欄位已用原始 xlsx 逐一核對）

以下 33 個相異欄位、共 33 條跨表引用（其中 BJ、BK、BL、BM、BN 這 5 欄都指向柏瑞印度同一個「斜率摘要列」（該基金表列1779左右）的 E–I 欄，性質相同，此處仍各自算一條），已用 parse_sheet_xml 直接讀原始 _recovered_基富投資1.xlsx 的 cached value 逐一比對「個股要點」端與「柏瑞印度」端，全部一致（33/33 OK，零落差），證實舊文件列出的引用完全正確，且未發現任何遺漏欄位（見下方「(b) 完整掃描結果」）。

(a) 核實結論：舊文件列出的 R/S/U/V/W/Y/Z/AA/AB/AD/AE/AI/AJ/AK/AL/AM/AN/AO/AP/AQ/AR/AS/AU/BF/BG/BH/BI/BJ/BK/BL/BM/BN/BU 共 33 個跨表引用全數正確，公式、儲存格位置、語意皆與原始 xlsx 相符。唯一需要更正的是：原查證草稿曾誤判 BL/BM 兩欄「來源表標頭其實是『10MA50』『10MA120』、與個股要點標頭不符」——實際用原始 XML 核對柏瑞印度 G1778/H1778 後，來源標頭就是「10EMA50」「10EMA120」，與個股要點自己的標頭完全一致，BL/BM 不存在標頭偏移問題（真正有偏移的只有 AQ/AR）。

(b) 完整掃描結果（用程式逐欄比對「r3」是否有公式）：除了上表 33 個跨表引用欄位外，列3還有 4 個同表內部（非跨表）公式欄，舊文件未提及，補充如下：

除以上 4 欄，其餘 L、N、O、P、Q、T、X、AC、AF、AG、AH、AT、AV、BV、CG、CP、CQ、CR、CU 等欄在列3–58完全沒有公式群組（用程式對 A–CW 每欄做逐欄掃描確認），代表這些欄位在 56 列基金區是純手動輸入/貼上值，不是公式驅動——包括看起來像「序號」的 L 欄（1–56 是手打數字，非公式產生）。

完整範例：柏瑞印度（列3）計算鏈解讀

1. 使用者在「柏瑞印度」工作表 Block3（近900筆五線譜）貼入最新淨值 → 觸發 BO4=SLOPE($BB$6:$BB$905,$AZ$6:$AZ$905)=0.0322175192（900日斜率）與 BR4=STDEVP($BQ$6:$BQ$905)=5.563958302（900日SD）。
2. 「柏瑞印度」自己的 BR3（用 EMA5 收盤點 BE905 判斷六段落點）算出 =1，BS3=(BM905−BP905)/BR905=-1.787390061（SD落點值）。
3. BX3/BX4/BX5/BX6/BX8 是分析師手動下拉輸入的位階與對策：BX3=1（價格線位階）、BX4=3（MA50位階）、BX5=3（MA120位階）、BX6="多-橫向整理[201]"（市場現狀）、BX8="加強增購"（對策）。
4. BX1=BO4/CA6=0.0322175192/89.667...≈0.0003593015185（b/MA120標準化，CA6＝最新MA120）。
5. 「個股要點」列3 用 33 條固定寫死目標表名的公式，把上述所有數字整批拉過來：AM3=柏瑞印度!BO4、AN3=柏瑞印度!BR4、AO3=柏瑞印度!BR3、AS3=柏瑞印度!BS3、AI3=柏瑞印度!BX3…BU3=柏瑞印度!BX8，形成使用者在總表上看到的一整列：

AM3=0.0322175192 | AN3=5.563958302 | AO3=1 | AS3=-1.787390061 | AI3=1 | AJ3=3 | AK3=3 | AL3="多-橫向整理[201]" | BU3="加強增購"。

1. 反向引用（重要，舊文件未提及）：「柏瑞印度」工作表本身的 BX2（參考市值標籤下方的值） 與 BX7（收益率標籤下方的值） 又回頭引用「個股要點」：

• 柏瑞印度!BX2 = 個股要點!BQ3（例：5418.09）
• 柏瑞印度!BX7 = 個股要點!BR3（例：-0.0411，收益率%）

也就是說「個股要點」BP/BQ/BR（投資本金/參考市值/收益率%）欄在列3–58沒有公式（見上方掃描結果），是分析師直接在總表上手動貼市值，然後由各基金自己的五線譜表反過來讀回這個手貼值顯示在自己表內（AW2=BX2）。用程式對 56 張基金表逐一 grep「個股要點!」確認，全部 56 張都有這組 BX2/BX7 ← 個股要點!BQ<row>/BR<row> 的回讀（例：柏瑞歐洲!BX2=個股要點!BQ4、元大台灣50!BX2=個股要點!BQ58），是系統性設計，不是柏瑞印度特例。這代表「個股要點」在「市值/收益率」這兩個欄位上其實是資料源頭，而非單純的彙總表，跨表引用方向是雙向的。 補充查證（原文未提及的小瑕疵）：把 56 張表的 BX2、BX7 目標列逐一與該表在「個股要點」R 欄的實際所在列比對後，發現有 5 張表的 BX2 與 BX7 指向不同列（同一張基金表內，市值回讀與收益率回讀對到了不同基金的列，屬於資料品質瑕疵）：野村全基建2（BX2→BQ50／BX7→BR53）、保德信ETF2（BX2→BQ51／BX7→BR50）、野村全品2（BX2→BQ52／BX7→BR51）、野村全高2（BX2→BQ53／BX7→BR52）、合庫台灣基（BX2→BQ54／BX7→BR55）。其餘 51 張表的 BX2/BX7 都精準對齊自己所在列。「每張表都有回讀」的結論仍成立，但「同一張表的 BX2/BX7 一定指向同一列」這個更強的假設並不成立，工程重建時必須各自取用兩者各自的目標列，不能假設兩者相同。

56 列基金 vs 57 張基金表：對應關係查證

活頁簿共 69 張工作表，扣除 6 張非基金輔助表（工作表1、基金程式規格、贖回損益、個股要點、單位淨值表格、TW50_OBV圖例）與 6 張暫存表（格式轉換 (5)(6)(7)(8)(9)(10)），剩下正好 57 張採用「基金五線譜模板」格式的基金表。

用程式把「個股要點」R3:R58 全部 56 條 =<某基金表>!G3 公式解析出目標表名，與 57 張基金表清單做差集，只缺一張：聯博房貸——與舊文件說法完全吻合，且已排除「還有其他遺漏」的可能（56 個引用目標名稱兩兩不重複，且恰好等於 57 張減去聯博房貸）。

補充查證細節：

• 全文 grep「個股要點.txt」找不到任何一處提及「聯博房貸」（不論在哪一欄），確認它是完全孤立、無任何進出引用的表。
• 反向也確認：grep「聯博房貸.txt」裡沒有任何「個股要點!」字樣，代表它連前一節提到的 BX2/BX7 ← 個股要點!BQ/BR 反向讀回機制也沒有——其餘56張基金表全部都有這組回讀。
• 「聯博房貸」（G2＝聯博-房貸收益基金AA(穩定月配)級別美元）結構上仍是同一套五線譜模板（Block1/2/3、BX/CA/CB 欄一應俱全），但其 Block1 最新資料日（G1248＝序號46051＝2026-01-29）明顯落後於其他仍在追蹤的基金（多數到 2026-04-17），推測是已出場/停止追蹤的舊持倉，被保留在活頁簿中僅供歷史查閱，這與舊文件「純觀察無對應列」的描述一致。
• 除聯博房貸外，其餘 56 張基金表與「個股要點」列3–58 是嚴格一對一：逐列核對 56 個 R[1 cells @ r3..r58] 公式引用的表名，彼此互不重複，也未見任何一張基金表被兩列同時引用的情形。

個股要點 ↔ 贖回損益：精確雙向引用關係

「贖回損益」工作表本身結構為列4起的贖回交易明細（A–I欄）+ 右側 K2:N10 的「帳戶彙總區」。跨表引用全部集中在 K2:N10，方向如下（已用原始檔案逐一核對公式）：

贖回損益 → 個股要點（5 條，公式寫在贖回損益，讀取個股要點的值）

個股要點 → 贖回損益（2 條，公式寫在個股要點，讀取贖回損益的值；舊文件/03文件未收錄，本次新查證）

串接鏈：使用者在「個股要點」C78（目前投資成本）與 D80（未實現損益）手動貼上最新數字 → 「贖回損益」L9/N6 讀走 → 算出 N8（累計贖回報酬率0.0517）、N9（目前投資浮動報酬率0.2073）、L10（帳戶預估淨損益＝已實現+未實現）、N10（帳戶預估總報酬率）→「個股要點」I77/I78 再把 N10、L10 讀回來顯示在總表右上角的迷你儀表板（列76–78）。這是一個完整的雙向循環，但因為讀寫的是不同列（個股要點寫 C78/D80/A80，讀回 I77/I78；贖回損益寫 L/M/N 欄，讀 個股要點 的 A80/C78/D80），所以沒有真正的循環參照錯誤。

異常、硬編碼與工程備忘

1. 標頭與實際內容不符（AQ/AR）：「個股要點」R2 標頭把 AQ 寫成「MA50-bias」、AR 寫成「MA120-bias」，但實際抓的柏瑞印度!BU3／BV3 分別是「MA20-bias（對EMA20）」與「MA50-bias（對MA50）」——即總表標頭比來源表的真實語意多偏移一格。此瑕疵存在於全部56列（因為每列都是同一套公式模式，只換目標表名），屬系統性而非個案問題。經覆核，緊鄰的 BJ/BK/BL/BM/BN（5EMA5斜率/10EMA20/10EMA50/10EMA120/2週斜率）標頭在來源表與個股要點兩端完全一致，沒有同樣的偏移問題，偏移僅發生在 AQ/AR 這兩欄。

1. I76/I77/I78 標頭與資料錯位：I76 標頭「帳戶預估淨損益」正下方的 I77 實際存的是百分比（帳戶預估總報酬率 30.1%），真正的「帳戶預估淨損益」金額（14,692,945.81）在下一列 I78，I78 所在列（78）反而被其他欄（F78=已實現台幣損益、G78=當日淨損益、H78=當日報酬率等）的文字標籤占滿，沒有自己的標頭欄位——這塊迷你儀表板的版面編排容易讓人誤讀數字。

1. D77/E77/G77 是「假公式」文字殘留，不是活公式：用原始 XML 核對後，這三格的儲存格類型是 t="s"（共用字串／純文字），完全沒有 <f> 公式元素——也就是說 =B47-C47、=D47/C47、=(B47-B48)-(C47-C48) 這幾串文字是被當成純文字直接打進儲存格的（可能是複製舊公式格時把顯示文字誤存成字串，或分析師刻意留作備忘），Excel 從未也不會對它們求值，本質上與「死公式」不同——它們不執行任何運算，不引用列47/48的真實資料，只是視覺上長得像公式的靜態文字。這點需要特別提醒工程團隊：若用「掃描以 = 開頭的儲存格內容」之類的粗規則去自動抓公式做遷移，可能誤把這三格當成需要轉換的計算邏輯，應明確排除（用 <f> 元素存在與否判斷，而非看儲存格顯示文字）。

1. 匯率是手動硬編碼常數：個股要點!U63 = 0.0315（美金/台幣，標籤在T63「美金/台幣=」）沒有任何公式來源，直接手打數字；「贖回損益」L6/M6 與「個股要點」內部多處（F495、F499、F502…、BP63/BQ63/BS63）都直接依賴這顆常數做美元→台幣換算。系統化時這是必須改成即時匯率來源或至少加上更新流程的高風險硬編碼點。

1. CT3 硬編碼帳戶總值：「個股要點」CR3:CU9 是另一個獨立的「金字塔投資額度法」迷你表（與57張基金表無關），CT3＝=1394990.6+51839.86（帳戶總值1,446,830.46）、CT4＝硬編碼20（預設投資基金數），這兩個是純數字/簡單四則運算，不是從其他工作表拉來的，每次資產總值變動都要人工改這兩格。

1. Y欄（星數）4處硬編碼覆蓋：列6（JPM美國科技）、25（利安新加坡1）、56（元大多福）、57（元大新主流）的 Y 欄是純數字 <v> 而非公式，其餘52列都是 =<基金表>!I3。用原始 XML 直接確認這4格完全沒有 <f> 元素，代表分析師手動覆蓋了星等，可能是原表星等有誤或該基金表資料不足時的人工修正，但也意味著這4檔基金的星數不會隨基金表更新自動同步。

1. BM26/BN26、BM42/BN42 完全空白（漏刻公式）：施羅德亞可換債（列26）與威博新非投債2（列42）的「10EMA120」「2週斜率」兩欄是空儲存格（無公式、無值），而同一基金表的來源資料其實是有效的——施羅德亞可換債!H1166=0.1420580808、I1166=0.54；威博新非投債2!H263=0.06193686869、I263=0.34——證實這不是來源資料缺失，而是「個股要點」這兩列在建立時單純漏刻了這2條公式（其餘31條都有），工程重建時要注意不能照抄「該基金無此資料」的結論，應直接用等價公式補回。

1. BS欄（市值佔比）公式列3–51與列52–58不一致：列3–51是 =(BQ_r)/$BQ$63，列52–58卻是 =(BQ_r*$U$63)/$BQ$63（多乘一次匯率U63＝0.0315），研判是列52–58這幾檔基金的BQ（參考市值）欄位分析師是用台幣輸入、其餘列是用原幣（多為美金）輸入，因此才需要多一次匯率轉換才能和以美金計的 $BQ$63 同基準相除；這是「個股要點」BP/BQ/BR手動輸入區沒有統一幣別規範的證據，系統化時務必在資料模型層面強制幣別欄位（X欄）與市值欄位聯動，不能讓使用者自行決定輸入幣別。

1. AC/AF/AG/AH（優先贖回權重#3/#5/#6/#13）完全空白：R1 列標頭把 AC/AF/AG/AH 標成「贖回優先順序」評分框架裡的 #3/#5/#6/#13，但列3–58（用程式掃描全範圍確認，不只列3–8）這幾欄完全沒有資料——顯示這套13因子評分框架設計出來後只有部分因子真正被填值使用（AA/AB/AD/AE/AI/AJ/AK/AL/AM/AN/AO/AP/AQ/AR/AS/AU 才有值），AC/AF/AG/AH 是設計時預留但從未啟用的欄位。

1. 序號欄（L）與交叉引用公式都是「寫死列號」而非查表：L3:L58＝手打1–56序號；R–BU的56組公式每一條都直接寫死目標工作表名稱與偏移列號（如 威博新非投債2!F263、柏瑞印度!G1779），完全沒有用 INDIRECT/INDEX MATCH/具名範圍等動態查表機制。這代表目前的Excel設計本身就是「一次性手刻」，重建為資料庫系統時，工程團隊應該用「基金代碼」或「工作表名稱」當 key 做正規化的一對多關聯，而不是模仿Excel按列硬寫目標表名。

1. BX2/BX7 反向讀回並非每張表都精準對齊自己所在列：見上方「反向引用」段落的補充查證——56張基金表雖然都有 BX2 ← 個股要點!BQ<row>、BX7 ← 個股要點!BR<row> 這組回讀，但其中 5 張表（野村全基建2、保德信ETF2、野村全品2、野村全高2、合庫台灣基）的 BX2 與 BX7 目標列彼此不一致，且與該表在 R 欄的實際所在列也有出入。重建系統時，市值與收益率的回讀路徑必須各自獨立核對來源列，不能假設「同一張表的兩個回讀欄位一定指向同一筆記錄」。

資料來源核對範圍：本文所有公式、儲存格位置、實際數值皆直接來自 data/_recovered_基富投資1.xlsx（透過 tools/extract_excel.py 讀取 cached value 與 <f> 公式元素）與其 dump 檔 tools/out/基富投資1/個股要點.txt、柏瑞印度.txt、柏瑞歐洲.txt、元大台灣50.txt、施羅德亞可換債.txt、威博新非投債2.txt、聯博房貸.txt、贖回損益.txt、_OVERVIEW.txt；並與 docs/excel/01-基金五線譜模板.md、docs/excel/03-贖回損益.md 交叉核對。所有列出的數字均可用文中給出的儲存格位址在原始檔重新查驗；未實際查到來源的項目本文未列入（查證過程中未遇到查無資料的欄位）。

本次品質查核修正說明：草稿絕大部分內容（33條列3跨表公式的位置與數值、聯博房貸孤立性、57張基金表對應關係、贖回損益雙向引用方向與公式、U63匯率硬編碼、Y欄4處覆蓋、BS欄公式分裂、BM/BN空白等）均已逐一以 parse_sheet_xml / 原始 XML 直接核對無誤。修正了以下 3 處與原始檔案不符或不夠精確之處：

1. BL（10EMA50）、BM（10EMA120）欄原文誤判來源表標頭為「10MA50」「10MA120」與個股要點不符——實際核對柏瑞印度 G1778/H1778 標頭就是「10EMA50」「10EMA120」，與個股要點標頭一致，不存在偏移（真正有偏移的只有 AQ/AR）。
2. D77/E77/G77 原文稱之為「殘留公式」，但原始 XML 顯示這三格是 t="s" 純文字儲存格、沒有 <f> 元素，並非會被求值的活公式，已更正說明其性質與對工程遷移的實際影響。
3. 補充查證發現 5 張基金表（野村全基建2、保德信ETF2、野村全品2、野村全高2、合庫台灣基）的 BX2/BX7 回讀目標列彼此不一致，原文「全部56張都有這組回讀、是系統性設計」的表述基本成立，但少了這個重要例外，已補充說明。另將欄位計數由「32個欄位」統一修正為與對照表實際列數一致的「33個」。

• L（無標頭）：R1、R2皆無任何表頭文字（openpyxl讀取L1、L2均為None），純資料欄。欄內56列全數為 L=列號-2 的等差序號（已逐列核驗r3-58全數符合，無例外），與P欄（斜率排名）目前數值完全相同，代表這批資料上次整理時排序與列序一致，之後若BH欄(5MA斜率標準化)變動，P欄需人工重排但L欄不需要（L只是列序）。另外，欄位字母『L』在同一張表的另一區塊（列94、119、142…等，屬列81-538『月獲利彙總』區的殘留公式，如 L94=J94/K94 月報酬率=月獲利/月平均市值）代表完全不同的意義，工程team比對時務必依列範圍區分，不可只看欄字母L。
• N（前次紀錄）：R1有『前次紀錄』字樣，R2該欄無文字（正式表頭列留空）。已逐列核驗，56個基金列中確實僅22列有填值（列3,5,6,7,10,11,15,17,18,34,40,41,44,48,49,50,51,54,55,56,57,58），其餘留白代表上次無特別記錄。書寫格式不統一，欄內確實同時出現「@100/環」(N41)「@300/美」(N44)「@250/環」(N48)等混合寫法，沒有標準化規則可循；本欄意義是依上下文與其他欄位（O、CQ對策等）交叉推測整理，並非分析師提供的官方定義，工程team若要結構化此欄，建議先與分析師確認每個簡記代碼的確切定義再設計資料模型。
• O（本次投資次序+量）：R1有『本次投資次序+量』字樣，R2該欄無文字。已逐列核驗，56列中確實33列有填值。美金計價基金（列3-51）填入的金額多落在1000~4000區間，台幣計價基金（列52-58）則為300000~400000區間，量級差異反映幣別單位不同，並非同一實質金額換算而來（若按匯率換算1000美金≈3萬台幣，遠低於觀察到的30~40萬台幣量級），推測台幣帳戶的單筆投入習慣本來就較大。此欄純人工填寫，不會隨任何公式自動更新。
• P（R1: " 1.斜率" / R2: "5MA斜率標準化由大至小"）：56列全數有填值。目前資料中P欄剛好等於「列號-2」（P3=1、P4=2…P58=56，已逐列核驗全數符合），亦即目前排名恰好與總表既有列順序完全一致——代表分析師上次整理時已依斜率排序過該表列，之後若基金工作表BH值變動，此欄不會自動更新，需人工重新排序才反映最新斜率。R1原文有前導空白「 1.斜率」，屬於R1這一整排『工作流程分類標籤』的一格（與O:『本次投資次序+量』相鄰，標示這一群欄位(P/Q)是用來做『1.斜率』篩選的）。
• Q（R2: "10MA20斜率標準化"（R1無文字））：已用逐列核驗列1-556的Q欄，確認除R2表頭文字『10MA20斜率標準化』（Q2一格）外，全表沒有任何其他儲存格有值或公式（Q3、Q4…Q58等資料列皆為完全空白的self-closing cell，非公式產生的空字串）。R1該欄亦無任何文字。屬於『有表頭但從未填資料』的欄位；若新系統要重建「個股要點」頁面，這個依10MA20斜率排名的功能等於未上線，需與分析師確認是否要新做或可略過。
• R（R1: " 2.投資建議" / R2: "基金號碼"）：R1該欄有『 2.投資建議』字樣，是分析師工作流程的分類註記，用來提示R~V這一路欄位是用於做『投資建議』判斷所需的識別資訊，並非說明R欄本身內容就是投資建議——R欄實際內容是基金代碼，容易讓人誤解，記錄與新系統設計時應澄清R1只是區塊起始標籤、非欄位真實意義。另外，列51(保德信ETF2)因基金工作表名稱結尾帶數字，個股要點.txt dump工具的公式『norm』欄會誤判成儲存格參照格式（顯示成類似=保德信ETFR[-49]!GR[-48]的誤標，已於dump檔核實存在此現象），這是抽取工具正規化regex的顯示瑕疵、非公式本身錯誤，實際公式仍是正常跨表引用=保德信ETF2!G3，請一律以每格『例』欄列出的原始公式為準。
• S（R1: " 3.低空間" / R2: "Yahoo 代號"）：R1該欄顯示『 3.低空間』（低價空間，可能是提示依價格落點篩選低接空間的工作步驟名稱），與S欄實際內容（Yahoo代號）完全無關，只是R1整排工作流程標籤中的一格——這是典型『R1分類標籤』與『R2/資料實際內容』脫節的例子，撰寫文件或設計新系統欄位說明時不要誤把R1文字當成S欄意義。同樣受列51基金工作表名稱含數字影響，dump工具『norm』欄顯示有誤（見R欄notes），請以『例』欄原始公式為準。
• T（R1: "4.>2.5%" / R2: "P與MA20的乖離由小至大"）：已逐列核驗，確認基金列3-58的T欄全數為空（T3、T52等皆為None）。欄位字母T在本表另一區段被挪作完全不同用途：T63='美金/台幣='（匯率換算標籤）、T78='月獲利率'、T80~T95為各月獲利率數值（屬列81-538『月獲利彙總』區塊，已逐一核對數值存在），皆與本欄（基金列3-58的排名用途）無關，比對時務必依列範圍區分。基金列範圍內的T欄與Q欄一樣，屬於『有表頭但從未填資料』的欄位，功能等於未上線。
• U（基金名稱）：R1、R2皆與其他多數欄不同——R1完全無文字（不像N、O、P在R1有標籤），正式表頭僅在R2。欄名雖為『基金名稱』，實質是『該基金工作表G2儲存格記錄的完整原始基金全名』，可能與系統其他地方使用的『基金工作表簡稱』（如柏瑞印度、JPM美國科技等，即公式中的<基金工作表>本身）不同，資料串接時要留意兩者不是同一字串，串接鍵應優先用R欄的基富通代碼或工作表名稱，不建議用U欄全名做join key。
• V（開始日期）：儲存格已套用日期格式，用openpyxl(data_only=True)讀取會回傳datetime並可正確顯示如2005-09-12；若改用純XML/zipfile手動解析（不套用cell number format）則只會拿到Excel日期序列值（如已核實V3快取序列值為46129，經1899-12-30基準換算確為2026-04-17屬同一天概念下的年份不同範例；本欄本身V3序列值另計，重點是工程team自行寫程式解析時需注意另外做序列值轉日期）。另外，同一欄字母V在別處有一筆完全不相干的殘留公式：V82='=38428/14+600'（已於dump檔核實），屬於列81-538『月獲利彙總』區塊的遺留內容，與V欄本身（開始日期）語意無關，可忽略。
• W（結束日期）：觀察列3-58共56檔基金的W欄快取值幾乎全部集中在2026-04-17（僅列28『歐義銳榮義大利卓越股票基金R2』為2026-04-16，早一天，已核實W28序列值46128對應2026-04-16、其餘核對列如W3/W52序列值46129對應2026-04-17），代表這是最近一次資料更新批次的『最後更新日』快照，並非每檔基金真正各自的最新交易日，實務上可視為『上次批次匯入淨值資料完成的日期』，用來粗略判斷整批資料是否已更新到最近。
• X（幣別）：本欄設有Excel資料驗證下拉清單，來源為$CP$3:$CP$5（CP3='美金'、CP4='台幣'、CP5為空），dataValidation的sqref涵蓋『V136:V1048576 X1:X71』（已於dump檔核實，選單值=['美金','台幣']），其中X1:X71正好覆蓋全部56檔基金列(3-58)。欄內為純文字值，不是公式，若基金實際計價幣別改變需人工重新從下拉選單選取，不會隨基金工作表自動連動。
• Y（星數）：查證發現Y6(JPM美國科技)、Y25(利安新加坡1)、Y56(元大多福)、Y57(元大新主流)這4列的儲存格是『純數字常數』而非公式（已逐一核實分別硬編為5、2、2、2），與其餘52列都是跨表公式=<基金工作表>!I3不同；代表這4列的星數若之後在對應基金工作表I3被更新，總表不會自動反映，需人工檢查更新，可能是當初公式意外被覆蓋為值。另外多列（如列20/21/23/32/33/35/36/37/42/45/46/47/48/49/50/51，已逐一核實快取值皆為'X'）的快取值為文字'X'，代表對應基金晨星無評等。
• Z（類別）：分類文字直接取自各基金工作表H3（晨星官方分類系統），非本系統自訂列表，故值的種類繁多且無固定字典（已逐列統計，現有56檔資料中實際出現29種不同分類文字，如『產業股票 - 其他』『積極型股債混合』『可換股債券 - 其他』等）。若新系統要做下拉篩選，建議做成動態抓取現有值的清單，而非寫死列舉，以免日後新增基金分類時漏掉。
• AA（斜率 b（R1標籤：#1））：N 欄公式使用絕對範圍 SLOPE，整欄皆同一常數值，所以無論引用 N4 或 N 欄其他任何列，取到的都是同一個『全歷史斜率』。已逐列（r3-r58）核對 56 組公式，樣式完全一致，美金列(3-51)與台幣列(52-58)無差異。同一列的 AD/AE 在『合庫台灣基』(r54) 出現 #REF!（見下），但 AA54 本身正常（0.01687643347），代表錯誤只發生在該基金工作表的 Q3/R3 摘要格，不影響 N 欄。
• AB（標準差（R1標籤：#2））：重要辨異：基金工作表的 Q 欄有雙重意義——Q3 是特殊摘要公式『落區(本日)』(IF巢狀分類1-6)，Q4 以下才是常態的 STDEVP 標準差常數。個股要點!AB 刻意取 Q4（拿標準差），而個股要點!AD 刻意取 Q3（拿落區分類）——兩者引用同一欄但不同列、意義完全不同，工程團隊複刻時務必分清楚，不能只看『都是 Q 欄』就當同一指標。
• AC（Div/P（R1標籤：#3））：已用程式逐列核對整欄（含 R3-R8 樣本列與程式化掃描列3/4/5/10/20/30/40/50/51/52/55/58，以及對 formulas/values 兩個結構做全欄掃描）：AC 欄在 d.formulas 中不存在此欄鍵，d.values 也只在列1、列2（即 R1/R2 表頭本身）有內容，列3以下（56支基金）全部是空格，確認為空欄。另外也搜尋過整張表其他欄位的公式文字，沒有任何公式把 AC 當作輸入來源，確認這是一個『被排序清單提及、卻從未接上資料』的死欄位。
• AD（落區本日）：此欄未出現在 R1 的排序優先權清單中（R1 只標了 AA=#1、AB=#2、AC=#3、AE=#4…AH=#13，中間跳過 AD），代表此欄是提供『參考位階』資訊，而非參與排序計分的量化指標。另：AD54（合庫台灣基）快取值為 #REF!，與《01-基金五線譜模板.md》§8/§10 記載一致——『合庫台灣基』該基金自己工作表的 Q3/R3 摘要格本身已損壞（Block 1 摘要壞），因此個股要點!AD54 與 AE54 都會回傳 #REF!，屬於來源端既有瑕疵，並非個股要點表公式寫錯；工程團隊在重寫時需對此類上游 #REF! 做容錯處理。
• AE（SD落點值（R1標籤：#4最近<4年資料））：與 AD 共用同一個上游摘要壞掉的問題：AE54（合庫台灣基）快取值為 #REF!，因為來源基金工作表自身的 Q3/R3 摘要公式已損壞（見 01-基金五線譜模板.md §8/§10）。另外 R1 附註『最近<4年資料』只是文字提醒，並未在公式中看到任何實際的年限過濾邏輯（沒有搜到引用 V/W 開始日期/結束日期做條件判斷的公式），也就是說這個排除規則目前僅存在於分析師的人工判讀習慣，尚未被公式或程式化邏輯真正落實，工程團隊若要自動化排序，需自行決定是否要新增這條『<4年資料需人工加註』的規則。
• AF（单位净值（R1標籤：#5））：已用程式對 d.formulas / d.values 做全欄掃描，AF 欄不存在任何公式鍵，數值僅存在於列1、列2（表頭本身），列3以下56支基金全空，也沒有其他公式引用 AF 作為輸入來源，確認為死欄位。系統中真正用來追蹤『現價/市值』的欄位是本表右側的 BP(投資本金)/BQ(參考市值)/BR(收益率%) 區塊，以及各基金自身五線譜工作表的 AL/BM 欄，並非透過 AF。
• AG（单位成本（R1標籤：#6））：已用程式對 d.formulas / d.values 做全欄掃描，AG 欄不存在任何公式鍵，數值僅存在於列1、列2（表頭本身），列3以下56支基金全空，也沒有其他公式引用 AG 作為輸入來源。實務上『持倉成本/收益率』是靠本表右側 BP(投資本金)/BQ(參考市值)/BR(收益率%) 這組欄位，以及每張基金工作表底部的『交易紀錄』區塊（科目類別/交易日期/單位數/止損價(實為成交淨值)/交易金額）在運作，AF/AG/AH 這一組『單位淨值/單位成本/總成本』的簡化設計看起來是被後者取代而廢棄。
• AH（总成本（R1標籤：#13））：已用程式對 d.formulas / d.values 做全欄掃描，AH 欄不存在任何公式鍵，數值僅存在於列1、列2（表頭本身），列3以下56支基金全空。值得留意的是 R1 排序編號的跳號現象：AG=#6 之後直接跳到 AH=#13，而緊接在 AH 右邊的 AI～AN 卻依序是 #7～#12（即 AI=#7、AJ=#8…AN=#12），代表 AH 在排序清單裡是被放在『最後一順位』而非依欄位順序排在 #7 之前——但因為 AH 本身完全沒有資料，這個順位設定目前是無效的死設定，工程團隊若要重建這套排序邏輯，需要向業主確認 AH(總成本) 這條規則原本想怎麼用、是否還要保留。
• AI（價格線）：BX3 本身即為 01-基金五線譜模板.md §3 所述「手動下拉」欄位（價格線位階），非公式運算結果，工程對應資料庫欄位時應視為人工評等值。唯一例外：列46（群益全成樂2）指向 AW3（該基金 Block2／Ⅱ期五線譜的另一組手動下拉，位置在 AV3:AW8）而非 BX3（Block3／900日五線譜的手動下拉），兩者是同一基金表裡『不同視窗』各自獨立填寫的位階，語意相同但取值可能不同步（本例 BX3=AW3=6，數值恰好一致，但同列 AL 欄的市場現狀在兩個區塊已不一致，見 AL 欄 notes）。經查該基金 max_row=1630，Block1 資料量遠大於其他表，研判是 900日固定視窗以外仍額外維護 Ⅱ期視窗判讀所致。R1 標籤為 #7。
• AJ（MA50）：BX4 為手動下拉，非公式運算。唯一例外同 AI 欄：列46（群益全成樂2）指向 AW4（Block2／Ⅱ期五線譜的對應手動下拉）而非 BX4（Block3／900日）。R1 標籤為 #8。
• AK（MA120）：BX5 為手動下拉，非公式運算。唯一例外：列46（群益全成樂2）指向 AW5（Ⅱ期版本）而非 BX5（900日版本）。R1 標籤為 #9。
• AL（市場現狀）：唯一形式異常：列46（群益全成樂2）指向 AW6（Ⅱ期版本）而非 BX6（900日版本）。已直接查證該基金工作表 BX6='多頭排列[012]'，但 AW6='空頭排列'——兩個判讀區塊的市場現狀分類實際『不一致』（非僅位置不同，數值本身互相矛盾），代表個股要點目前顯示的是與900日主視窗（Block3）不同調的舊/替代判讀，工程團隊移植時必須與業務確認何者才是權威值，不能假設兩者等價。R1 標籤為 #10。
• AM（斜率 b）：已用查詢確認 BO4 對每張表整欄同值（=BO6 等）。經查威博新非投債2、野村全基建2 兩檔基金彼此完全不同的基金，其 Block3 摘要值 BO4/BR4/BR3/BT3/BS3 竟完全相同（如兩者 BO4 皆＝0.0007778978501，BR4皆＝0.1757430644），高度懷疑這兩檔的 Block3（900日視窗）本身已損壞或公式失效（該文件已知威博新非投債2 CK/CL x範圍為 #REF!，可能是同類問題的延伸）；個股要點作者疑似因此手動改指向仍正常的 Block2（Ⅱ期）欄位 AN4 作為替代來源。列46（群益全成樂2）改指 AN4 原因未明（其自身 BO4=0.007082328661 看似正常，非損壞值），仍建議工程team向業務確認取數邏輯。R1 標籤為 #11。
• AN（標準差）：同 AM 欄異常：列42/46/50 改指向 Block2（Ⅱ期）的 AQ4 而非 Block3（900日）的 BR4；威博新非投債2 與野村全基建2 兩檔基金的 BR4 快取值同樣完全相同（皆＝0.1757430644），與 AM 欄一致地指向 Block3 摘要可能損壞。R1 標籤為 #12。
• AO（落區本日）：⚠️真正的公式錯誤（非佈局位移可解釋）：列35（摩根歐機）指向 Q3，即基金工作表 Block1（全歷史五線譜）的落區(本日)，而非 Block3（900日）的 BR3。已直接查證兩者數值不同：摩根歐機!Q3=2，摩根歐機!BR3=1——代表個股要點目前顯示的是『全歷史落區』而非標頭所稱的『900日落區』，兩者評等基準不同（全歷史用收盤價判定、900日用EMA5判定），移植時必須修正為 BR3。另有列42/46/50 沿用與 AM/AN 相同的 Block2 替代模式（改指 AQ3），原因推測同 AM 欄。
• AP（TL-bias）：標頭與公式語意一致，無誤植問題。僅列42/46/50 沿用與 AM/AN/AO 相同的 Block2 替代模式（BT3→AS3），語意仍是 TL-bias，只是統計視窗換成 Ⅱ期而非900日。
• AQ（ MA50-bias）：任務要求特別查核的標頭誤植已確認屬實：AQ標頭寫『MA50-bias』但53檔正常基金公式指向 BU3＝對EMA20的乖離率（已交叉核對 01-基金五線譜模板.md §3：BU3標籤即為『MA20-bias』，公式=(BM905−BF905)/BF905對EMA20）。另發現更嚴重的錯誤：列15（貝萊智數環小）指向 BX4——即『MA50位階』手動下拉的整數(1-3)，完全不是乖離率百分比。已查證 貝萊智數環小!BX4=1，與個股要點 AQ15 快取值=1 吻合，證實此列數值型態與其餘所有列（小數乖離率）不一致，屬公式錯誤而非取數邏輯差異，移植時必須排除或修正。標頭本身還帶有一個原始檔案就存在的前置空白字元（R2原文『AQ= MA50-bias』）。
• AR（ MA120-bias）：任務要求特別查核的標頭誤植已確認屬實：AR標頭寫『MA120-bias』但53檔正常基金公式指向 BV3＝對MA50的乖離率。同樣發現與 AQ15 成對的錯誤：列15（貝萊智數環小）指向 BX5——即『MA120位階』手動下拉整數(1-3)，非乖離率。已查證 貝萊智數環小!BX5=1，與個股要點 AR15 快取值=1 吻合，確認為公式錯誤（很可能是 AQ15/AR15 這兩格在複製/拖曳時一起被貼到相鄰的 BX 手動下拉區，而非正確的 BU/BV 乖離率區）。標頭原文『AR= MA120-bias』同樣帶前置空白字元。
• AS（SD落點值）：標頭與公式語意一致，無誤植問題；列15（貝萊智數環小）在此欄正常指向 BS3（未如 AQ15/AR15 般出錯），可見該基金的異常僅限 AQ/AR 兩格。僅列42/46/50 沿用與 AM/AN/AO/AP 相同的 Block2 替代模式（BS3→AR3）。R1 未給予此欄任何 #N 優先順序標籤（AI-AN 有 #7-#12，AO-AS 皆無），研判 AO-AS 屬輔助參考指標而非直接列入排序評分公式的欄位，但仍會被分析師人工參考用於判斷操作力道。
• AT（R1=#1；R2=每次可投資）：已用Python逐格查詢第1~556列（USD列r3-51、TWD列r52-58、以及r59以後全表）確認：AT欄唯二有內容的儲存格只有 AT1='#1'、AT2='每次可投資' 兩個表頭，AT3:AT556 全部沒有公式也沒有快取值（既非公式也非手動填寫的殘留資料）。屬於「有表頭、資料列全空」而非「完全無表頭」，因此 source 依欄位設計用途記為手動輸入而非「無資料」，但務必提醒工程團隊：目前沒有任何歷史值可回填，此欄若要在系統UI呈現，需與業務確認是否要開放人工輸入或先行隱藏/留待未來使用。
• AU（R1=優先贖回0或最小值與與5MA5標準化斜率相對最小；R2=現價與最高價的差比）：公式本身在USD列與TWD列的樣式完全一致（皆抓各自基金工作表的BY3），未發現標頭文字與公式指向不符的情形（不像AQ/AR有標頭錯置的問題）。此欄不是資料驗證下拉選單，是純公式結果。抽查多列數值皆≤0，符合「回撤」定義；例如AU5（柏瑞環重股）、AU52（野村全品2）、AU55（合庫台灣高科）快取值皆為0，代表當下淨值剛好等於900日內最高價。
• AV（R1=#3；R2=可投資額度）：已用Python逐格查詢第1~556列確認：AV欄唯二有內容的儲存格只有 AV1='#3'、AV2='可投資額度' 兩個表頭，AV3:AV556 全部沒有公式也沒有快取值。與AT情況相同，屬於「有表頭、資料列全空」；source依欄位設計用途記為手動輸入，工程團隊需與業務確認是否要開放輸入，目前無任何歷史值可回填。
• BE（R1=#12；R2=（該儲存格空白，無R2表頭文字））：R2該儲存格本身是空白的（Python直接查證 BE2 回傳 None），只有R1有'#12'編號，整理文件時容易誤植成與R2同義詞，需特別註明。BE欄的56個儲存格公式群組在原始抽取檔中被歸為單一種樣式（=BUR[+0]），與本組其他欄位（AU/BF/BG/BH/BI）每列各自一條跨表公式的模式不同，請工程團隊留意這是「同表引用」而非「跨表引用」。
• BF（R1=#13；R2=b/MA120標準化）：標頭（R2='b/MA120標準化'）與實際公式指向的基金工作表欄位意義（BX1='b/MA120標準化'，即 =BO4/CA6）完全一致，未發現如AQ/AR那種標頭與公式指向不符的情形。USD列與TWD列公式樣式一致，僅目標基金工作表隨列變化。
• BG（R1=加碼考量順序：1.趨勢 : 5MA5斜率>10MA20斜率>0， 2.空間位置， 3.現價與20MA的乖離率。；R2=P與MA20的乖離率標準化）：標頭寫「P與MA20的乖離率標準化」，但依01-基金五線譜模板.md，來源儲存格CA7在基金工作表上被稱為「P與MA20的乖離率」（公式是單純比值 (CD5−CA4)/CA4），並未額外做統計學上的標準化(如z-score)運算，「標準化」三字屬沿用命名慣例、非新增運算，數值意義仍一致，並非像AQ/AR那樣的公式指向錯誤，僅提醒工程團隊理解為「乖離率」即可。另外R1的完整說明文字是理解AT、AU、AV、BE、BF、BG、BH、BI這整組欄位業務邏輯的關鍵，建議技術文件把這8欄放在同一節說明並引用這段R1原文。
• BH（R1=（無，該儲存格為空）；R2=5MA5斜率標準化）：標頭（R2='5MA5斜率標準化'）與公式指向的基金工作表欄位意義（CA2='5MA5斜率標準化'，即 =$BZ$3/$CA$3）完全一致，未發現標頭與公式不符的情形。此欄R1本身為空白，沒有額外註解文字；完整的檢核清單說明文字掛在同組的BG1上。
• BI（R1=（無，該儲存格為空）；R2=10MA20斜率標準化）：標頭（R2='10MA20斜率標準化'）與公式指向的基金工作表欄位意義（CB2='10MA20斜率標準化'，即 =BZ4/CA4）完全一致，未發現標頭與公式不符的情形。此欄R1本身為空白，沒有額外註解文字。
• BJ（5EMA5斜率）：56列全部有公式，無缺列。每列的跨表位移量（R[+n]）都是硬編碼且各不相同，因各基金歷史資料長度不同（276~2712筆），並非可套用單一固定公式；新系統重建時應改為「依基金工作表當前最後資料列動態定位」，不可原樣複製這種寫死列號的公式。重大資料品質問題（原稿誤判為無害位移，已修正）：威博新非投債2（r42）目前抓的是F欄（值0.2030514674），但直接查證該基金分頁自己的斜率摘要列（263列）中，E263=0.46416430768（公式=A257）才是真正的5EMA5斜率值；F263=0.20305146743其實是該基金的「10EMA20」斜率值（公式=SLOPE(AE248:AE257,D248:D257)，且與同分頁Block1的B257=0.20305146743完全一致，可交叉驗證），並非5EMA5。也就是說BJ42目前顯示的0.2030514674不是該基金的5EMA5斜率，而是被錯置的10EMA20斜率值，會誤導分析師對該基金短線動能的判斷。該分頁自身資料並未位移（263列E/F/G/H/I仍正常對應5EMA5/10EMA20/10MA50/10MA120/2週斜率），問題出在「個股要點」總表建立r42整列公式時referencing欄位多移了一欄（該分頁另有CK/CL公式壞成#REF!的已知結構異常，屬不同問題，勿混淆）。新系統重建時，此列應改抓E欄（=威博新非投債2!E263）才能取得正確的5EMA5斜率，不可比照現有F欄公式原樣搬移。
• BK（10EMA20）：56列皆有公式，無缺列，模式與BJ完全一致（僅目標欄從E換成F）。位移量同樣逐基金硬編碼。與BJ同一批資料品質問題：威博新非投債2（r42）目前抓的是G欄（值0.01453454545），但已查證該基金分頁F263=0.20305146743才是真正的10EMA20斜率值；G263=0.01453454545其實是該基金的「10MA50」斜率值（公式=SLOPE(AF248:AF257,D248:D257)，與同分頁Block1的C257=0.01453454545完全一致）。即BK42目前顯示的0.01453454545不是10EMA20斜率，而是被錯置的10MA50斜率值。新系統重建時此列應改抓F欄（=威博新非投債2!F263）才是正確的10EMA20斜率。
• BL（10EMA50）：⚠️標頭「10EMA50」與實際抓取的指標不符：來源欄BG按基金分頁模板（docs/excel/01）定義是MA50（簡單移動平均），本欄實質是「10MA50斜率」而非EMA50斜率，屬模板既有命名瑕疵（與AQ/AR的MA/EMA混用是同一類問題，但這是獨立一起的誤植，非同一個瑕疵；AQ/AR不在本次指派範圍內，僅作參照）。工程團隊補齊系統欄位時，欄位說明文字建議標註清楚是MA50而非EMA50，避免依表頭字面誤植成EMA計算。56列皆有公式，無缺列。另一項獨立的資料品質問題（與BJ/BK同一次建表錯誤，原稿未發現，已補上）：威博新非投債2（r42）目前抓的是H欄（值0.06193686869），但已查證該基金分頁G263=0.01453454545才是真正的10MA50斜率值；H263=0.06193686869其實是該基金的「10MA120」斜率值（公式=SLOPE(AG248:AG257,D248:D257)）。即BL42目前顯示的0.06193686869不是10MA50斜率，而是被錯置的10MA120斜率值。新系統重建時此列應改抓G欄（=威博新非投債2!G263）才是正確的10MA50斜率。
• BM（10EMA120）：重要缺陷：56列中有2列（r26施羅德亞可換債、r42威博新非投債2）本欄完全空白（既無公式也無快取值），但已直接查證這兩檔基金工作表對應的來源儲存格本身確實有計算值（施羅德亞可換債!H1166=0.1420580808、威博新非投債2!H263=0.06193686869，且其Block3資料完整），代表原始建表時這兩列的BM欄漏拖曳公式，並非來源沒有資料。此處引用的H263是該基金263列真正對應「10MA120」語意的儲存格（與BJ/BK/BL欄位位移問題不同，BM/BN是單純空白、非取錯欄，兩者不可混為一談，詳見BJ notes）。新系統補齊此頁面時需與業務端確認：是要「忠實重現Excel的空白」還是「回填正確跨表引用值」。另外標頭「10EMA120」與實際抓取的「10MA120」不符（見meaning）。
• BN（2週斜率）：與BM共用同樣的2列缺公式問題（r26、r42），且是同一次操作漏掉的（同一批列、同一種缺法），研判是建表時BJ/BK/BL三欄有拖曳、但BM/BN兩欄在這兩列被跳過。已查證來源基金表對應儲存格（施羅德亞可換債!I1166=0.54、威博新非投債2!I263=0.34）確實有值，同BM的處理建議：需與業務端確認是否要回填。補充：r42同一列的BJ/BK/BL雖非空白，但已查證其取值實際上是被錯置的其他指標（見BJ notes），BM/BN反而是「單純空白」而非「取錯欄」，重建時兩類問題須分開處理，不可套用同一種修法。
• BO（市場現狀）：本欄與AL欄內容100%重複，是版面配置上的冗餘欄位；若新系統只需保留一份資料，建議以AL的來源公式（<基金工作表>!BX6）為準，BO視為顯示層別名即可。另外要特別提醒：BO63這格例外地被借用來放純文字標籤「總計USD」（不是公式、也與市場現狀無關），是帳戶彙總小區塊（BO63/BP63/BQ63/BR63/BS63同列）的欄位借用，重建UI時不要把它誤當成第57列的市場現狀資料。
• BP（投資本金）：逐基金列完全沒有公式，是人工每次交易後手動更新的資料，無法從基金分頁自動同步（也查證加總結果BP63=1472252.045與總表頂端時間序列B4「投資本金 USD」完全一致，代表r63是每次更新後拿來覆寫B欄最新一筆記錄的來源）。新系統若要免人工維護，需另外設計「投資本金」的交易彙總機制（例如從交易紀錄自動加總），不能只是把Excel公式原樣搬過去，因為這裡本來就沒有公式。
• BQ（參考市值）：同BP，逐列無公式，全靠人工更新（可能是分析師對照基金公司對帳單、或用持有單位數×最新淨值手動算出後貼上）；已驗證加總值BQ63=1668436.76與總表頂端C4「參考市值 USD」一致。這是整張表最需要人工維護、也最容易延遲更新（與基金分頁實際淨值脫勾）的欄位；建議新系統改為公式化（持有單位數×最新淨值自動計算）而非人工輸入。
• BR（收益率 %）：重要提醒：BR3=-0.0411經核算等於BQ3/BP3-1（5418.09/5650.2-1≈-0.0411），數值邏輯正確，但逐基金列本身完全沒有公式，正確性完全仰賴分析師在更新BP/BQ後「記得」手動重算並填入BR，任何一次疏漏都會讓BR顯示與最新BP/BQ不同步的舊收益率。新系統應把BR做成真正的即時公式（=BQ/BP-1）而非另一個要手動同步的欄位，避免資料落後風險。
• BS（市值佔比）：USD列與TWD列公式確實不同（TWD列多一段*$U$63匯率換算），實作時務必依幣別分流，不能對所有列套同一條公式。另外查得BS71（=SUM(BV5:BV53)，值66）是本欄唯一語意不符的孤例：座標雖在BS欄，卻是加總「配息」欄BV第5~53列，與「市值佔比」定義完全無關，且同列（第71列）左右其他欄位（A~BT）皆為空白、沒有任何文字標籤說明用途，研判是分析師借用空白儲存格做過一次性計算後留下的殘留，非UI設計的一部分。建議重建系統時忽略此儲存格，但仍建議跟業務端確認一次以免遺漏隱藏用途。
• BT（市值排名）：無USD/TWD公式差異（因BS已先統一換算成美金基礎的占比，可直接跨幣別排名）。56列皆有公式，查證期間未發現缺列或例外。
• BU（對策）：r50（野村全基建2）是56列中唯一一個抓Block2(AW8)而非Block3(BX8)的例外。依基金分頁文件，AW8＝Ⅱ期摘要區的手動下拉、BX8＝900日主視窗摘要區的手動下拉，兩者語意相同（都是「當前對策」）但屬不同分頁區塊，資料可能不同步更新。建議向業務確認野村全基建2是否為特殊情況（例如該基金歷史資料相對較短，900日主視窗尚未有足夠資料，分析師才改填在Ⅱ期區）。其餘55列公式一致，無缺列。
• BV（配息（R1補充註解；R2正式標頭該儲存格為空白））：1) 正式欄位標頭（R2）在BV位置是空白，「配息」二字只出現在R1補充註解列，是本表少數「正式標頭缺失、要靠註解列才知道欄位名稱」的例子，工程團隊補文件時務必註明此欄名稱來源是R1而非R2。2) 重大公式異常：BV62標籤「合計台幣」理論上應該加總7列台幣計價基金的配息（=SUM(BV52:BV58)），但實際公式卻是單一儲存格參照=BV22（第22列「利安越南1」的配息值），而BV22剛好是空白，所以BV62恆顯示0，並非真正的「台幣基金配息加總」，明顯是複製/拖曳公式時起點或方向算錯所致的殘留錯誤。新系統若要重建「配息加總」邏輯，不可原樣照抄BV62的公式，必須改成正確的=SUM(BV52:BV58)。