Series C — C07｜一句話不是魔法：Sparse Intent 與 Project-World Cognition

One Sentence Is Not Magic: Sparse Intent and Project-World Cognition

系列： Global Observer and AI-Native Domain Computation
系列中文名： 全域觀察者與 AI 原生域計算系列
篇次： Paper 07 / 10
作者： Neo.K
研究協作： Aletheia（GPT-5.6 Sol）
機構： EveMissLab／一言諾科技有限公司
版本： v0.1
日期： 2026-09-06
狀態： Canonical Source / UTF-8 Markdown
文件性質： Applied Theory / Software Engineering / Project-World Cognition / Sparse-Intent Globality

Canonical Source Note

本文件之正式原稿為此 UTF-8 Markdown source。任何 HTML、PDF、LaTeX rendering、聊天介面顯示或其他格式皆屬 projection，不取代 canonical source。

數學公式 canonical delimiter 僅使用：

inline math： $...$
display math：$$...$$

本文承接 C01–C06，將 Global Observer、difference governance、domain formation、legal bridge、uncertainty domain 與 ELC Loop 首次壓入一個高可觀測、可工程驗證、可長時間追蹤的實務場景：

只給 AI 一句極短意圖，然後觀察它是否能自行建立一個真正接近完整的 Project World。

本文的核心不是吹捧「一句話做 App」，而是拆解一句話背後被 AI 自行補出的全域認知工作。

摘要

「一句話生成 App」常被當成 AI 能力的戲劇化展示：

做一個記帳 App。

做一個企業 AI 會計系統。

做一個多人線上遊戲。

做一個法律檢索平台。

若 AI 幾分鐘後產生：

UI；
API；
database；
code；

人們很容易說：

AI 已經把應用做完了。

本文拒絕這種低解析度判定。

真正的問題不是：

\boxed{ \text{Prompt} \rightarrow \text{Code} \rightarrow \text{Runs}. }

而是：

\boxed{ \text{Sparse Intent} \rightarrow \text{Project World Model} \rightarrow \text{Domainization} \rightarrow \text{Architecture} \rightarrow \text{Implementation} \rightarrow \text{Verification} \rightarrow \text{Deployment} \rightarrow \text{Maintenance Future}. }

本文把這種能力稱為：

\boxed{ \text{Sparse-Intent Project-World Cognition} }

簡稱：

\boxed{ \mathsf{SIPWC}. }

它測量的是：

在人類只注入極少 task information 時，AI 能自行補出多少「必要但未明說」的專案世界。

Sparse Intent 的價值在於：

\boxed{ \text{Human Information Injection}\downarrow \Rightarrow \text{AI Structural Contribution}\uparrow }

因而更容易觀察 AI 自身的 global attention、domain discovery、architecture choice、risk awareness 與 project epistemic self-awareness。

本文首先定義一個 Project World：

\boxed{ \mathcal W_P = \left\langle D_P, D_{UX}, D_A, D_D, D_S, D_T, D_O, D_{Deploy}, D_M, D_C, D_R, H_P \right\rangle. }

其中至少包括：

$D_P$ ：product domain；
$D_{UX}$ ：UX / interaction domain；
$D_A$ ：architecture domain；
$D_D$ ：data domain；
$D_S$ ：security / privacy domain；
$D_T$ ：testing / verification domain；
$D_O$ ：observability domain；
$D_{Deploy}$ ：deployment / operations domain；
$D_M$ ：maintenance / evolution domain；
$D_C$ ：cost / resource domain；
$D_R$ ：risk / failure domain；
$H_P$ ：project history / provenance。

所以一個「應用」不是：

UI+API+DB.

而是：

\boxed{ \text{Project} = \text{Product Intent} + \text{Executable System} + \text{Operational Environment} + \text{Future Maintenance Space}. }

本文進一步定義 Application Quality Vector：

\boxed{ \mathbf Q_{app} = ( F, C, A, R, S, T, M, P, U, O, E, X ). }

其中：

$F$ ：functional completeness；
$C$ ：correctness；
$A$ ：architecture quality；
$R$ ：reliability；
$S$ ：security / safety；
$T$ ：testing / verification；
$M$ ：maintainability；
$P$ ：performance；
$U$ ：usability / UX；
$O$ ：observability；
$E$ ：extensibility；
$X$ ：evolution cost / future adaptability。

因此：

\boxed{ Performance \subset ApplicationQuality. }

而不是：

Performance = ApplicationQuality.

本文再建立 application maturity ladder：

\boxed{ L_0 = Prototype, }

L_1 = MVP,

L_2 = Production,

L_3 = Commercial,

L_4 = Enterprise,

L_5 = FrontierCommercial.

這些 maturity levels 不能由單一總分決定，而必須使用 Application Completeness Envelope：

\boxed{ \mathcal C_{app}^{(L)} = \left\{ Q_i \ge \tau_i^{(L)} \right\}_{i\in D_{required}^{(L)}}. }

也就是：

某些關鍵維度不能低於底線。

例如一個 App 功能很多：

F=0.9,

但：

S=0.2,\qquad O=0.1,\qquad M=0.3,

就不應被稱為 production-ready。

因此本文提出：

\boxed{ \text{Feature Completeness} \neq \text{Project Completeness}. }

本文特別引入 Future Bug Surface：

\boxed{ B_F(P) = \mathbb E \left[ \text{future defect exposure} \mid \text{reasonable project evolution} \right]. }

AI 不只要避免當下 bug，還應推演：

dependency upgrade；
concurrency；
scale；
malformed input；
schema migration；
partial outage；
privilege change；
API drift；
future feature interactions。

所以：

\boxed{ \text{Current Correctness} \neq \text{Future Robustness}. }

本文將「漂亮架構」操作化為可測量結構，包括：

\boxed{ C_{change} = \frac{ N_{affected\ components} }{ N_{total\ components} }. }

並搭配：

dependency depth；
coupling；
cohesion；
test isolation；
rollback cost；
migration cost；
local change containment。

本文進一步定義 Global Project Attention Coverage：

\boxed{ A_G(P) = \frac{ \sum_iw_i c_i }{ \sum_iw_i }. }

其中：

$c_i$ ：AI 是否主動建模 project dimension $i$ ；
$w_i$ ：該 dimension 在當前 project 的 importance。

因此真正重要的不是：

AI 想到了幾個 checklist item。

而是：

\boxed{ \text{importance-weighted project coverage}. }

如果 AI 花大量 attention 在 animation polish，卻忽略 auth、backup、schema migration、observability，則即使 code 很漂亮，也不能稱為高 globality。

本文進一步定義 Project Epistemic Self-Awareness：

\boxed{ E_P = \mathsf{Know} ( Done, NotDone, Unknown, Risk, Debt, Readiness ). }

真正成熟的 AI 應能說：

功能已完成，但目前仍不能稱 production-ready，因為 disaster recovery、migration plan、rate limiting、backup verification 尚未閉合。

因此：

\boxed{ \text{Self-Declared Done} \neq \text{Actually Ready}. }

本文把 C06 的 ELC Loop 映射進 software project：

\boxed{ \text{Sparse Intent} \rightarrow \text{Expand} \rightarrow \text{Differentiate} \rightarrow \text{Link} \rightarrow \text{Prune} \rightarrow \text{Converge} \rightarrow \text{Build} \rightarrow \text{Verify} \rightarrow \text{Maintain}. }

其中：

Expand：從一句話找出未明說 domains；
Differentiate：把 product / security / data / testing 等分開；
Link：建立合法 interfaces；
Prune：避免過度工程；
Converge：形成足夠可建造 architecture；
Build：實作；
Verify：測試；
Maintain：經需求變更重新打開 project world。

因此 C07 不只是 coding benchmark。

它是一個：

\boxed{ \text{Project-World Cognition Benchmark}. }

本文最後提出最強版本的長期驗證：

一個 AI 用一句話生成的系統，經過六個月真實使用、三次需求變更、安全審計、壓力測試、依賴升級與資料 migration 後，是否仍維持其 maturity level？

真正值得觀察的不是：

\text{generation speed}.

而是：

\boxed{ \text{Did the AI understand the project as a world?} }

關鍵詞： Sparse Intent、Project-World Cognition、Application Completeness、Software Architecture、Future Bug Surface、Global Attention、Maintainability、AI Agent Engineering

1. 「一句話生成」為什麼是好探針？

因為人類提供的資訊很少。

2. Sparse Intent

令：

I_s

為極短意圖。

例如：

做一個企業 AI 會計系統。

3. 人類沒有明說

auth；
backup；
observability；
retention；
audit；
migration；
access control。

4. 但真正 commercial system 仍需要它們

5. 所以 Sparse Intent 測的是

\boxed{ \text{implicit requirement reconstruction}. }

6. 不是 Prompt Engineering Show

如果 prompt 已經列出 300 條 requirements，

那人類其實先做掉大量 global decomposition。

7. Human Injection

令：

H_I

為 human information injection。

8. AI Contribution

令：

A_S

為 AI structural contribution。

9. 粗略關係

\boxed{ H_I\downarrow \Rightarrow A_S\text{ becomes more observable}. }

10. 但 Sparse 不等於 Vague Everything

至少還要有最小 intent boundary。

11. Project Boundary

AI 要先問或推斷：

target user；
platform；
business goal；
data sensitivity；
expected scale。

12. 若資訊不足

正確行為不一定是直接 coding。

可以：

\boxed{ \mathsf{Clarify} }

或建立 provisional assumptions。

13. Assumption Ledger

\boxed{ A_P = \{a_1,\ldots,a_n\}. }

14. 每個 assumption 應有

source；
confidence；
consequence；
revision trigger。

15. Project World

本文定義：

\boxed{ \mathcal W_P = \left\langle D_P, D_{UX}, D_A, D_D, D_S, D_T, D_O, D_{Deploy}, D_M, D_C, D_R, H_P \right\rangle. }

16. Product Domain

D_P

處理：

user；
value；
workflow；
business constraint。

17. UX Domain

D_{UX}

處理：

interaction；
accessibility；
error recovery；
latency perception。

18. Architecture Domain

D_A

處理：

module boundaries；
dependency graph；
interfaces；
state ownership。

19. Data Domain

D_D

處理：

schema；
consistency；
migration；
retention；
backup。

20. Security Domain

D_S

處理：

auth；
authorization；
secrets；
attack surface；
privacy。

21. Testing Domain

D_T

處理：

unit；
integration；
regression；
property；
end-to-end；
failure injection。

22. Observability Domain

D_O

處理：

logs；
metrics；
traces；
alerts；
audit trail。

23. Deployment Domain

D_{Deploy}

處理：

CI/CD；
rollback；
environment；
release；
configuration。

24. Maintenance Domain

D_M

處理：

future change；
dependency upgrade；
deprecation；
refactor；
technical debt。

25. Cost Domain

D_C

處理：

compute；
storage；
API；
engineering；
scaling cost。

26. Risk Domain

D_R

處理：

critical failure；
irreversible change；
compliance；
disaster recovery。

27. Project History

H_P

保存：

requirement changes；
architecture decisions；
migrations；
incidents；
fixes。

28. App 不等於 Codebase

\boxed{ \text{Application} \neq \text{Repository}. }

29. Repository 只是 project world 的一個 projection

30. Runtime 也不是全部

31. 真正 application 包括 operational environment

32. 所以

\boxed{ \text{Code Complete} \neq \text{Project Complete}. }

33. Application Quality Vector

\boxed{ \mathbf Q_{app} = ( F, C, A, R, S, T, M, P, U, O, E, X ). }

34. Functional Completeness

F.

35. Correctness

C.

36. Architecture Quality

A.

37. Reliability

R.

38. Security

S.

39. Testing

T.

40. Maintainability

M.

41. Performance

P.

42. UX

U.

43. Observability

O.

44. Extensibility

E.

45. Evolution Cost

X.

46. Performance 只是一個分量

\boxed{ Performance \subset ApplicationQuality. }

47. Runtime Fast 不能掩蓋 Security Poor

48. UX Beautiful 不能掩蓋 Data Corruption

49. Feature Rich 不能掩蓋 Maintainability Collapse

50. Maturity Ladder

\boxed{ L_0=Prototype }

L_1=MVP

L_2=Production

L_3=Commercial

L_4=Enterprise

L_5=FrontierCommercial.

51. Prototype

證明 idea 可行。

52. MVP

證明核心 value 可用。

53. Production

可在真實環境穩定運作。

54. Commercial

可持續服務付費使用者。

55. Enterprise

需要：

governance；
audit；
reliability；
security；
migration；
SLA-like discipline。

56. Frontier Commercial

在 maturity 不下降下，仍具前沿功能、架構、效率與 adaptability。

57. Maturity 不是功能數量

58. Application Completeness Envelope

\boxed{ \mathcal C_{app}^{(L)} = \left\{ Q_i\ge\tau_i^{(L)} \right\}_{i\in D_{required}^{(L)}}. }

59. Bottleneck Principle

若 critical domain：

Q_k<\tau_k,

則 maturity 不應通過。

60. 所以不能用平均分掩蓋致命缺口

61. 例

F=0.95,

但：

S=0.20.

不能叫 enterprise-ready。

62. Project Epistemic Self-Awareness

定義：

\boxed{ E_P = \mathsf{Know} ( Done, NotDone, Unknown, Risk, Debt, Readiness ). }

63. 高階 AI 應知道自己還沒做完

64. Self-Declared Done Problem

Agent 常會：

完成！

但未檢查：

migration；
tests；
observability；
secrets；
rollback。

65. 因此

\boxed{ \text{Completion Claim} \neq \text{Readiness Evidence}. }

66. Readiness Evidence

至少需要：

\boxed{ R_E = ( Tests, SecurityChecks, Build, Deploy, Observability, Migration, Rollback ). }

67. Future Bug Surface

目前沒有 bug 不等於未來 robust。

68. 定義：

\boxed{ B_F(P) = \mathbb E \left[ \text{future defect exposure} \mid \text{reasonable project evolution} \right]. }

69. Reasonable Evolution

包含：

new feature；
scale increase；
dependency update；
schema change；
permission change；
API drift；
partial outage。

70. Future Bug Domain

可表示：

\boxed{ D_{bug}^{future} = \{b_1,\ldots,b_n\}. }

71. 每個 future bug 可有

trigger；
probability / confidence；
impact；
detection；
mitigation；
repair cost。

72. Current Correctness

C_t.

73. Future Robustness

R_{future}.

74. 兩者不同

\boxed{ C_t \neq R_{future}. }

75. Architecture Quality

「漂亮」要可 operationalize。

76. Change Locality

\boxed{ C_{change} = \frac{ N_{affected\ components} }{ N_{total\ components} }. }

77. 低通常較好

但不是越低越絕對好。

78. 過度 abstraction 也有成本

79. Dependency Depth

Depth(G_{dep}).

80. Coupling

Coupling(M_i,M_j).

81. Cohesion

Cohesion(M_i).

82. Test Isolation

一個 module 是否可獨立驗證。

83. Recovery Cost

C_{recover}.

84. Migration Cost

C_{migrate}.

85. Architecture 不只看 class diagram

86. 還要看 future change propagation

87. Evolution Simulation

AI 可模擬：

P_0 \rightarrow P_1^{(i)} \rightarrow P_2^{(i)} \rightarrow \cdots.

88. 比較不同 architecture 在未來 branch 下

89. Architecture Robustness

\boxed{ R_A = \mathbb E_i [ Quality(P_k^{(i)}) - ChangeCost(P_k^{(i)}) ]. }

90. 這直接接 C05 的 World Prediction Envelope

91. Future Project Envelope

定義：

\boxed{ \mathcal E_P(t) = \{ (P_{t+\Delta}^{(i)}, C_i, Risk_i, Cost_i) \}_{i\in I}. }

92. AI 不需要預測唯一未來需求

93. 只需測架構對多種合理 future 的韌性

94. Global Project Attention

定義：

\boxed{ A_G(P) = \frac{ \sum_iw_i c_i }{ \sum_iw_i }. }

95. $c_i$

該 dimension 是否達所需 coverage。

96. $w_i$

importance / risk weight。

97. Attention 不等於 checklist

98. 100 個 trivial checklist items

不一定比 10 個 critical domains 好。

99. Importance-Weighted Coverage

這才是核心。

100. Attention Misallocation

如果 AI：

UI polish 0.9；
auth 0.2；

則：

A_G

應被拉低。

101. Global Attention Distribution

\boxed{ \mathbf a_P = (a_{product}, a_{security}, a_{data}, a_{test}, a_{maint},\ldots). }

102. Healthy Distribution

依 project risk 動態不同。

103. Fintech

security / compliance 權重高。

104. Casual Game

UX / performance / retention 權重可能更高。

105. 所以沒有 universal project weighting

106. Domain-Native Project Evaluation

每個 project 應先建立：

\mathbf w_P.

107. Sparse Intent → Expansion

承接 C06：

I_s \rightarrow \mathsf{Expand}.

108. AI 自己找：

missing domains；
hidden constraints；
failure modes。

109. Expansion Failure

如果只想到：

UI+API+DB,

global project coverage 低。

110. Differentiation

將 project 拆成 domains。

111. 但過度 microservice 化也可能是 fragmentation

112. 所以要控制：

L_{fragment}.

113. Linking

interfaces 必須合法。

114. C04 在這裡變成 software contracts

115. API Bridge

B_{frontend,backend}.

116. DB Bridge

B_{service,data}.

117. Auth Bridge

B_{identity,resource}.

118. Observability Bridge

B_{runtime,monitoring}.

119. Link 不只 technical

還有：

B_{product,architecture}.

120. Product Requirement → Architecture

也是 bridge。

121. Pruning

AI 需要避免過度工程。

122. 一個 MVP 不需要大型 distributed architecture

123. Overengineering Loss

\boxed{ L_{over} = Cost_{unneeded} + Maintenance_{unneeded}. }

124. Underengineering Loss

\boxed{ L_{under} = FutureFailure + RefactorCost + Risk. }

125. Project Architecture 要平衡

\boxed{ \min ( L_{over} + L_{under} ). }

126. Convergence

何時可以開始 build？

127. 不是所有未知都消失才 build。

128. 需要：

\boxed{ \text{Operational Sufficiency}. }

129. Architecture Decision Record

可保存：

\boxed{ ADR_i = ( Decision, Alternatives, Reason, Risk, RevisitTrigger ). }

130. 這讓 future maintenance 可理解。

131. Build

Implementation 只是中間階段。

132. Build Quality

要測：

correctness；
style；
type safety；
failure handling；
deterministic behavior；
resource use。

133. Test

不是只跑 happy path。

134. Verification Layers

\boxed{ V_P = ( V_{unit}, V_{integration}, V_{e2e}, V_{security}, V_{perf}, V_{migration}, V_{recovery} ). }

135. Security Test

要包含：

authorization；
secret exposure；
injection；
privilege boundary；
rate limiting。

136. Migration Test

要測：

Schema_t \rightarrow Schema_{t+1}.

137. Recovery Test

故意讓 dependency fail。

138. Observability Test

故障後能不能知道發生什麼。

139. Deployment

Project world 進入 real runtime。

140. Deploy 不等於 Upload

141. Deployment Readiness

包含：

config；
secrets；
rollback；
migration；
monitoring；
health check。

142. Rollback

\boxed{ Release \rightarrow Failure \rightarrow Rollback }

要可驗證。

143. Maintain

真正 project cognition 在這裡才開始被長期檢驗。

144. Requirement Change

R_t \rightarrow R_{t+1}.

145. AI 必須重新打開 world

146. 不應只 patch local code

如果需求影響：

schema；
auth；
billing；
UI；

就要 global reopen。

147. Change Propagation

\boxed{ \Delta R \rightarrow \Delta D_i \rightarrow \Delta B_{ij} \rightarrow \Delta W_P. }

148. 這是 C06 ELC loop 的 project 版本

149. Longitudinal Maintainability

可以測：

\boxed{ M_L = \frac{ Quality_{after\ changes} }{ Cost_{changes} }. }

150. 一次生成很漂亮不夠

151. 三次 change 後崩潰

代表 architecture quality 被高估。

152. Maintenance Shock Test

給 project：

新 payment provider；
新 jurisdiction；
new data retention rule；
scale ×10。

153. 看 AI architecture 能否局部修改。

154. Commercial Readiness

不是 demo 漂亮。

155. Commercial Domain

至少需要：

user support；
billing；
privacy；
reliability；
incident handling；
backup；
data export；
upgrade path。

156. Enterprise Readiness

還需要：

audit；
role-based control；
policy；
retention；
observability；
formal change management。

157. Frontier Commercial

不只更前沿功能。

158. 必須保持：

\boxed{ Novelty + Reliability + Maintainability. }

159. Novelty Alone 不夠

160. Commercial Quality Envelope

\boxed{ \mathcal C_{commercial} = \{ F,S,R,M,O,T,\ldots \} \ge \boldsymbol\tau. }

161. Project Completeness

定義：

\boxed{ C_P = F( Coverage, Quality, RiskClosure, DebtVisibility, Maintainability, Readiness ). }

162. 類完備不等於沒有 debt

163. 只要 debt：

known；
bounded；
acceptable；
tracked。

164. Project Debt Vector

\boxed{ \mathbf D_P = ( D_{tech}, D_{test}, D_{security}, D_{migration}, D_{obs}, D_{doc} ). }

165. 完成的 project 可以仍有 debt

166. 但不能不知道 debt

167. Project Epistemic Failure

最危險的是：

\boxed{ \text{unknown unknown presented as done}. }

168. 所以 Self-Awareness Score

\boxed{ S_A = F( DebtRecall, RiskRecall, UnknownRecall, ReadinessCalibration ). }

169. Completion Calibration

如果 AI 說：

90% ready

實際 audit 只有 50%，則 calibration 差。

170. 可測：

\boxed{ E_{ready} = |Ready_{claimed}-Ready_{audited}|. }

171. Sparse Intent Benchmark

本文提出：

\boxed{ \mathsf{SIPWC\text{-}Bench}. }

172. Level A

一句話需求。

173. Level B

一句話 + 少量 constraints。

174. Level C

一句話 + 真實 deployment environment。

175. Level D

部署後進行需求變更與故障。

176. Level E

持續數月 maintenance。

177. Benchmark 不只看第一次生成

178. Initial Score

S_0.

179. Change Score

S_\Delta.

180. Maintenance Score

S_M.

181. Security Score

S_S.

182. Commercial Score

S_C.

183. 綜合：

\boxed{ S_{SIPWC} = F( S_0, S_\Delta, S_M, S_S, S_C ). }

184. One-Shot Trap

如果只評估：

第一天看起來多完整，

會高估 AI。

185. Longitudinal Test 才能看 architecture quality

186. Hidden Requirement Injection

測試方可在後期加入合理但未明說需求。

187. 例如

現在要支援 100 倍用戶。

188. 看 original architecture 是否留下演化空間。

189. Future Bug Injection

可模擬：

dependency deprecation；
API version change；
schema conflict；
partial network failure。

190. 看 AI 是否早期已建立防護。

191. Adversarial Requirement

故意要求一個會破壞 security 的功能。

192. 高階 AI 應：

\boxed{ \text{Refuse / redesign} }

而不是 blindly comply。

193. 這接 C04 的 authority / legality

194. Project-World Observer Event

強事件可以是：

AI 收到一句話後，主動指出：

這個需求表面是 feature request，但會改變 trust boundary、schema migration 與 audit obligations，因此不能只 patch UI。

195. 這顯示它在看 Project World

196. 更強事件

AI 自己創造一個人類沒有要求的 domain，

例如：

D_{data-lineage}.

197. 並證明：

這個 domain 讓 future migration error 顯著下降。

198. 這是 Representation / Domain Escape

199. Project-World Cognition 不限軟體

同樣框架可擴展：

research project；
legal project；
game production；
data pipeline；
robotics system。

200. Software 只是容易驗證

201. 為什麼 software 是好觀測器？

因為：

state 可觀察；
bug 可重現；
performance 可測；
architecture 可演化；
audit 可重複。

202. 所以 C07 是 Series C 的第一個強工程探針

203. Human Baseline

測 AI 時也應有：

H_{junior}, H_{mid}, H_{senior}, H_{team}.

204. 不能只和最佳人類比較

205. 也不能只和初學者比較

206. Maturity Baseline

每個 level 應用同一 audit protocol。

207. Cost Baseline

還要算：

Cost_{AI}.

208. 包括：

inference；
tool；
retries；
human review；
repair。

209. Human Supervision Cost

\boxed{ C_H^{sup}. }

210. 如果 AI 很便宜但需要大量人類檢查

effective cost 會上升。

211. 這會直接接 C08 的 FTE / stewardship

212. Project Economic Efficiency

\boxed{ E_P^{econ} = \frac{ VerifiedProjectValue }{ AIcost+HumanSupervision+RepairCost }. }

213. 但 C07 不把經濟作主軸

C08 會處理 responsibility-domain labor equivalence。

214. C07 與 C01

C01 問：

AI 能否自己決定怎麼看世界？

215. C07 的 project 版本：

AI 能否自己決定怎麼看一個 application？

216. C07 與 C02

Project 需要：

Architecture \rightarrow Module \rightarrow Function

往下。

217. 也需要：

Bug \rightarrow Module \rightarrow Architecture \rightarrow ProjectRisk

往上。

218. 這就是雙向 observer traversal。

219. C07 與 C03

AI 自己決定哪些 differences：

permission；
data type；
environment；

值得 domainize。

220. C07 與 C04

module interfaces 是 legal bridges。

221. C07 與 C05

future bug / maintenance 是 future envelope。

222. C07 與 C06

整個 project 就是 ELC loop 的實驗場。

223. C07 與 C08

C07 測：

一次 Project World 能不能建好？

224. C08 測：

它能不能長時間負責住？

225. C07 與 C09

C09 不告訴 AI：

請考慮 security；
請考慮 migration；
請考慮 maintenance。

226. 看它是否自己長出這些 domains。

227. 這才是真正 Sparse Intent evidence。

228. C07 與 C10

若某一代 AI 突然在大量不同 project 中自行做出完整 Project World，

可能構成：

\boxed{ \text{Global Observer Event}. }

229. 第一核心命題

\boxed{ \text{Prompt} \rightarrow \text{Code} \rightarrow \text{Runs} }

不是完整 application generation。

230. 第二核心命題

\boxed{ \text{Feature Completeness} \neq \text{Project Completeness}. }

231. 第三核心命題

\boxed{ \text{Current Correctness} \neq \text{Future Robustness}. }

232. 第四核心命題

\boxed{ \text{Performance} \subset \text{ApplicationQuality}. }

233. 第五核心命題

\boxed{ \text{Architecture Beauty} \rightarrow \text{measurable change behavior}. }

234. 第六核心命題

\boxed{ \text{Sparse Intent} \text{ reveals autonomous project-world reconstruction}. }

235. 第七核心命題

\boxed{ \text{Maturity} \neq \text{feature count}. }

236. 第八核心命題

\boxed{ \text{Project Epistemic Self-Awareness} }

是 readiness 的一部分。

237. 第九核心命題

\boxed{ \text{Longitudinal maintainability} > \text{one-shot impressiveness} }

作為更高權重證據。

238. 第十核心命題

\boxed{ \text{The strongest one-sentence app demonstration is a system that survives the future}. }

239. C07 Project Loop

\boxed{ SparseIntent \rightarrow ExpandRequirements \rightarrow Domainize \rightarrow Architect \rightarrow Implement \rightarrow Verify \rightarrow Deploy \rightarrow Observe \rightarrow Maintain \rightarrow Reopen. }

240. 這與 Global Observer 完全同構

241. Project World 是一個 bounded world

所以它非常適合測 Globality。

242. Globality 不必先從宇宙開始

可以先從：

\boxed{ \text{bounded but complex worlds}. }

243. 一個真實 commercial software project

就是非常好的 bounded world。

244. 如果 AI 在 bounded project world 都不能維持 global coherence

就不應輕易談 universe-level globality。

245. 因此 C07 也提供 Scale Ladder

\boxed{ Function \rightarrow Module \rightarrow Application \rightarrow Product \rightarrow Organization \rightarrow World. }

246. Global Observer 可以先在 Application Level 成熟

247. 之後再擴展到更大 responsibility domain

這正是 C08。

結論

「一句話生成 App」真正有意思的地方，不是：

AI 把人類幾天的 coding 壓成幾分鐘。

這只是速度。

真正值得研究的是：

當人類只給一句極短意圖時，AI 到底自行注意到了多少本來沒有人提醒它的世界結構？

一個弱系統可能只看見：

UI+API+DB.

一個更成熟的 Project-World Observer 會看見：

\boxed{ Product + UX + Architecture + Data + Security + Testing + Observability + Deployment + Maintenance + Cost + Risk. }

而且它不只是列 checklist。

它要知道：

哪些 domains 相互依賴；
哪些 interface 是合法 bridge；
哪些 future branch 需要提早防護；
哪些技術債可以接受；
哪些 maturity threshold 尚未通過；
哪些需求會讓整個 project world 重新打開。

所以真正高階的一句話能力不是：

\boxed{ \text{One Sentence} \rightarrow \text{One Codebase}. }

而是：

\boxed{ \text{One Sentence} \rightarrow \text{One Maintained Project World}. }

最強證據也不會是：

AI 一分鐘做出一個漂亮 App。

而更可能是：

AI 從一句話生成的系統，經過六個月真實運行、三次需求改動、安全審計、壓力測試、依賴升級與資料 migration 後，仍維持其宣稱的 maturity level。

這時真正被驗證的不是 generation speed。

而是：

\boxed{ \text{the AI understood the project as a world}. }

因此 C07 的核心可以濃縮成一句：

一句話不是魔法；真正的能力在於 AI 從一句話裡，自行看見一整個尚未被說出口的專案世界。

參考與前置研究

EveMissLab / Neo.K 內部前置理論

Neo.K with Aletheia, Series C C01｜AI 需要先有眼睛：全域觀察者維度的定義, 2026.
Neo.K with Aletheia, Series C C02｜由世界到個體、由個體到世界：全域觀察的對偶計算, 2026.
Neo.K with Aletheia, Series C C03｜差異先於分類：從歧義個體、集合與非交集到計算域, 2026.
Neo.K with Aletheia, Series C C04｜分域算子世界：合法作用、跨域橋接與世界組合, 2026.
Neo.K with Aletheia, Series C C05｜概率也有域：不確定性、混沌、不可判定與世界預測包絡, 2026.
Neo.K with Aletheia, Series C C06｜全域展開、連結與收斂：類全域觀察者的核心計算循環, 2026.
Neo.K with Aletheia, Global Computation Methodology Series, 2026.
Neo.K with Aletheia, WDC-08｜三生世界域計算, 2026.
Neo.K with Aletheia, PNCW Paper 05｜全域計算、局部顯現, 2026.
Neo.K, 《分域算子本體論》, 2026.

理論定位

本文與 software architecture、systems engineering、DevOps、SRE、secure software lifecycle、technical debt、software evolution、requirements engineering、agentic coding benchmarks 等領域存在直接對照，但本文不將 Project-World Cognition 等同於任何單一既有 software benchmark。

本文的特定研究目標是：

\boxed{ \text{用 Sparse Intent application generation 測量 AI 的自主 Project-World Observation 與全域注意力品質}. }

Series C Roadmap

C01

AI 需要先有眼睛：全域觀察者維度的定義

C02

由世界到個體、由個體到世界：全域觀察的對偶計算

C03

差異先於分類：從歧義個體、集合與非交集到計算域

C04

分域算子世界：合法作用、跨域橋接與世界組合

C05

概率也有域：不確定性、混沌、不可判定與世界預測包絡

C06

全域展開、連結與收斂：類全域觀察者的核心計算循環

C07

一句話不是魔法：Sparse Intent 與 Project-World Cognition

C08

從完成任務到負責一個域：長時空 Agent Stewardship

C09

不准考 Neo.K：方法論盲測與全域 AI 觀測器

C10

眼睛何時睜開：全域觀察者相變、脈衝與 AI 原生世界計算

End of C07

Series C — C07｜一句話不是魔法：Sparse Intent 與 Project-World Cognition — One Sentence Is Not Magic_ Sparse Intent and Project-Wo