I always thought that as long as you described your requirements clearly and assigned a role to the AI, you were good to go. The myriad of complex prompt tutorials, “Chain of Thought” (CoT) techniques, and the very title of “Prompt Engineer” felt overhyped. As someone writing scripts and building personal projects, I simply didn’t think I needed that level of complexity.
However, after spending the last six months heavily relying on various AI tools for a relatively large personal website project, my perspective has completely flipped.
While pushing my project forward, I essentially test-drove all the mainstream tools. They all have their strengths, but also their fatal flaws:
Implementation Plan.md. For sheer project execution, I prefer it over Gemini. The dealbreaker? Network instability. Once the project scales or requirements stack up, it drops connections constantly.Eventually, the actual execution almost always falls back to the VSCode Copilot Agent. Instead of just using it as an autocomplete tool or a code encyclopedia, I now use the Agent features to directly edit, generate, and debug code.
But as the Agent took over more responsibilities, three infuriating pain points emerged:
git commit obsessively just to survive).The turning point came when Claude’s system prompts leaked recently. Reading through those, along with other viral system prompts, it hit me: Advanced prompting isn’t about teaching the AI how to talk; it’s about injecting global behavioral constraints and rules into the Agent.
Combining this with my pain points, I completely overhauled my workflow.
First, I forced the AI to scan the core files of my project and generate a Global Architecture Document. Previously, I avoided this to save Tokens. But I changed my mindset: if Tokens are expensive, make the AI take “notes” like a human developer. Once that architecture doc is set, it becomes the “Constitution” of the project.
I then wrote a set of constraints for the AI:
if-else.By leveraging Github Actions and these rules, I created a set of Copilot Repository Instructions. It’s basically a hardcore instruction manual for the AI. Now, every action is traceable. Surprisingly, Token consumption dropped because the AI knows exactly where to look instead of guessing.
The biggest takeaway from this entire process? If you nail the prompt inputs and set up a solid constraint document (like CLAUDE.md), the AI’s ability to understand and implement code is lightyears ahead of us. But—and this is a massive “but”—AI still sucks at system architecture.
We used to say architecture was important; now, it’s a matter of life and death for a project.
Architecture requires high cohesion, loose coupling, systemic thinking, human intuition, and a bird’s-eye view. In a poorly structured project, AI will only accelerate the mess. In a cleanly architected, modular project, AI gives you superpowers.
The core value of a senior engineer is shifting from “manually writing features” to “designing systems that allow AI to work efficiently.” Hardcore skills like system design, modularization, and scalability haven’t depreciated—if anything, they are more valuable today than ever. AI can write test cases in seconds, but defining boundaries and structuring directories still requires a human brain.
I realize I might just be catching up to what big tech companies are already doing internally, but arriving at this realization firsthand was crucial for me.
My current prompt workflow is still somewhat basic. If I pivot to robotics or embedded systems, I’ll definitely need domain-specific constraints. What does a system prompt look like for a 0-to-1 project? That requires more experimentation.
I’m also looking into setting up a local LLM-powered Wiki to internalize these workflows. Next up, I plan to take this “vibe coding” experience and apply it to some hardware/software integration projects in robotics.
The barrier to writing code has been flattened by AI. Moving forward, the only truly scarce resource is crazy, rigorously thought-out ideas.
]]>我总觉得只要把需求描述清楚、给AI设定个角色就足够了。网上那些错综复杂的提示词教程、所谓的“思维链（CoT）”，甚至“Prompt工程师”这个头衔，在我看来都有些过度包装。对于日常写写脚本的我来说，似乎真用不上那么复杂的玩法。
但最近在做一个体量稍大的个人网站项目时，这大半年重度使用各家AI的经历，让我彻底推翻了之前的想法。
在实际的项目推进中，我几乎把主流的工具试了个遍，发现它们各有千秋，但也各有各的致命伤：
Implementation Plan.md。从项目实施的完整性来说，它优于 Gemini。但致命伤是网络连接极不稳定，项目一大、需求一多就容易“歇菜”。兜兜转转，最后的落地执行往往又回到了 VSCode 里的 Copilot Agent。现在我不再单纯把它当“自动补全器”或“百科全书”，而是直接让它去编辑、生成代码并 Debug。
但随着 Agent 接管的工作越来越多，三个让我非常抓狂的痛点开始浮现：
git commit 来续命）。转机发生在最近 Claude 系统源码（System Prompt）的泄露事件。阅读那些泄露的文档，包括前阵子爆火的“小龙虾”系统提示词，我突然意识到：高级的 Prompt 根本不是在教 AI 怎么说话，而是在给 Agent 注入全局的行为准则和约束条件。
结合我遇到的痛点，我开始尝试一套全新的工作流：
首先，我让 AI 扫描整个项目的核心代码，强制它输出一份《全局架构文档》。以前我觉得每次让 AI 读全量代码太费 Token，但现在我转换了思路——既然 Token 贵，那就让 AI 像人类程序员一样“做笔记”。架构文档一旦定好，这就成了项目的“宪法”。
我甚至给 AI 写了一套类似模板的约束规则：
if-else 补丁。补丁打多了牵一发而动全身，不如一开始就在架构层解决。借助 Github Actions 和这套规则，我最终形成了一套 Copilot Repository Instructions。这相当于给 AI 配了一本《项目操作手册》。现在它在干活前，不仅要验证结构，干完活还要写更新日志。动作有迹可循，Token 消耗反而少了，因为它知道去哪里精准找代码。
在这个过程中，我最大的感触是：只要需求输入得当，规范文档（如 CLAUDE.md）设置好，AI 在具体代码的理解和实现上已经遥遥领先了。但是，AI 目前依然设计不好系统架构。
以前我们常说“架构重要”，现在我想说“架构是生死线”。
架构代表着高内聚、松耦合的系统性思考，它需要人类的经验、判断力和全局视野。一个架构混乱的项目，AI 只会越帮越忙，加速其屎山化；而一个架构清晰、模块化的项目，AI 能够如虎添翼。
未来核心工程师的价值，正在从“纯手工实现功能”转移到“设计出能让 AI 高效工作的系统”。系统设计、模块化封装、可扩展性……这些传统的“硬功夫”在 AI 时代不但没有贬值，反而变得比以前更值钱了。目前，AI 写测试用例非常神速，但梳理和定义那些扫描目录的功能、界定各个函数的边界，依然需要人脑来把关。
我最近才真正“悟”到这套大厂可能早已在用的工作流。但这个摸索的过程对我意义重大。
目前这套 Prompt 玩法还比较初级。未来如果涉足机器人开发或嵌入式系统，针对不同的工具链，肯定还需要制定专门的 Prompt 规范。如果是一个从 0 到 1 的全新 Idea，系统级提示词又该怎么写？这都是需要持续验证的。
最近我也在考虑搭建本地的大模型知识库（Wiki），把这些经验内化。下一步，我打算带着这套 Vibe Coding 的经验，去尝试一些机械、机器人相关的软硬件结合项目。
毕竟，写代码的门槛已经被 AI 踏平了，现在真正稀缺的，是那些疯狂而又严谨的 Idea。
]]>Numerical Analysis (often referred to as “Computational Methods” in engineering undergraduate courses) is a subject I have gained a deeper appreciation for after studying it systematically during both my undergraduate and graduate studies. I am compiling these thoughts into a blog series, hoping to provide some help to future learners.
This series is primarily based on Professor Lei Wu’s course MAE5002 Advanced Numerical Analysis at Southern University of Science and Technology. I gained a lot from his classes and lecture notes. I also benefited from the solid foundation laid by Professor Qi Li from Chang’an University during my undergraduate studies. After taking Numerical Analysis again as a graduate student, I finally had a moment of enlightenment. I would like to express my sincere gratitude to both teachers.
As my knowledge is limited, these articles are mainly for recording my own thoughts and outputs. There may be errors or lack of rigor, so please bear with me and I plan to correct them!
I think when you are learning a new course, you should ask yourself three questions, simply put: What? Why? How?
Learning with questions allows you to grasp the core of the course more accurately, avoiding the confusion of “feeling meaningless after learning”. During the learning process, your perception of these three questions will gradually deepen, which is actually a manifestation of your deepening mastery of the course.
We cannot expect to get the essence right from the start, but it is this process of continuous optimization and iterative cognition that deepens understanding. This is the essence of learning; do not learn just for the sake of learning.
During my undergraduate studies, I realized: Numerical Analysis is actually studying how to make computers understand real physical problems and solve them.
For humans, we tend to prefer analytical solutions. For example, a quadratic equation has a root-finding formula, which is its analytical solution. But if you were asked to find the numerical solution of a complex equation (such as the root of $x^5 + x + 1 = 0$), you might not know where to start.
Computers are different from humans. It might be very difficult for them to derive analytical solutions, but they are extremely good at massive calculations. Therefore, I thought at the time that “Computational Methods” was about teaching computers how to calculate numerical solutions of equations (especially differential equations). Although this view seems a bit simple in retrospect, it was enough for a beginner to establish this cognition.
In my subsequent studies, my strategy was to practice programming more. Being able to write the program shows that you have a relatively solid grasp of the relevant algorithm logic. You really have to understand it, not just memorize it.
However, in my undergraduate studies, I focused mainly on the algorithms themselves and ignored many derivation processes. Although I thought I understood it well at the time, after retaking the course in graduate school, I found that simply staying at the “algorithm” level without digging into the mathematical connections between different parts caused me to fail to grasp the thread running through them, even though I knew Numerical Analysis had different sections.
Ignoring the derivation process means ignoring the source of the algorithm, making it difficult to dig deep or modify it, and losing the space for deep thinking. This also reminds everyone not to be satisfied with just knowing how to use it.
Many disciplines are essentially explaining the physical world. Based on various physical laws, we obtain a series of equations.
Most systems we encounter in high school are idealized and simplified models. But the real physical world is often described by differential equations (such as Fourier’s Law of Heat Conduction). Let’s look at it from simple to complex:
From the simplest linear equation in one variable (describing the motion of a ball in the x-direction) to linear equations in two variables. Solving them manually is simple. But for computers? You can’t manually adjust the code for every equation form. What if the equation has 1000 unknowns? Writing 1000 layers of for-loops is obviously neither elegant nor realistic.
To be concise and elegant, we need to establish a processing paradigm. No matter how many unknowns the equation has, it can be solved in the same way. Smart readers may have thought of it—Linear Algebra. We can write the equations in matrix form $Ax=b$ and solve them uniformly using linear algebra methods.
After establishing this paradigm, solving is no longer a problem, but in engineering, computation volume and efficiency become key. Real-world simulations (such as Finite Element Analysis) often involve millions of nodes, forming huge systems of equations. If an algorithm can reduce calculation time by half, in today’s expensive computing power era (students in AI know this well), the value is immense. Therefore, how to improve the solution efficiency of linear systems is a deep-water zone in Numerical Analysis.
In the real world, gravity and electromagnetic forces are inverse square forces, and trajectories are ellipses, parabolas… these are all non-linear.
Since general analytical solutions are not possible, computers need to use numerical iteration (such as Bisection Method, Newton’s Method). This constitutes an important section of Non-linear Equation Solving in Numerical Analysis. Similarly, discussions on computational efficiency and convergence speed are involved here.
Students familiar with computers know that computers cannot store true “continuous” values; they can only save discrete points.
Interpolation is a method of inferring new data points within a range from known discrete points. For example: You have three discrete points and want to know the value between them.
This is the core of interpolation: finding a function to accurately describe these points. This is crucial in signal processing and image reconstruction.
Here we must distinguish Fitting: Interpolation requires the function to pass through every known point; while Fitting only seeks a function to approximately describe the overall trend of the data (such as Least Squares), allowing for errors.
We’ve talked about ideal equations, now back to differential equations. How do computers do calculus?
Calculus theory is “continuous”. But in numerical methods, we need to discretize it, which is Numerical Differentiation and Numerical Integration. Recall the definition of calculus:
In Numerical Analysis, we use difference to replace differentiation, and rectangle/trapezoid area sum to replace integration. Interpolation ideas are often used here as well, deriving differentiation or integration formulas by constructing interpolation polynomials. Finally, combining these tools allows us to solve complex Differential Equations.
The above is the preliminary picture I hope everyone can establish. The various sections of Numerical Analysis (Linear Algebra, Non-linear Equations, Interpolation, Calculus) are not isolated, but closely connected toolkits.
In the AI era, you might feel: “AI can write code now, do I still need to learn these theories?” My answer is: Absolutely.
AI can write good code, but the premise is that your Prompt logic is clear and your requirement description is accurate. This requires you to master the underlying theories. If you only have a smattering of knowledge about the theory, it is difficult to direct AI to generate correct results, or to know how to Debug when the results are wrong.
AI is not omnipotent. Currently, it can only function within existing knowledge bases. Facing a brand new complex engineering problem, a clear theoretical framework + accurate problem description is the key to making AI perform at its best.
This is my shallow understanding. If the Numerical Analysis series blog can be rewarding for some people, it will be very meaningful. I hope everyone maintains critical thinking, does not accept blog content completely, but internalizes it into their own knowledge.
]]>数值分析（在工科本科课程中常被称为“计算方法”），是我在经过本科及研究生两次系统学习后，感触颇深的一门学科。
这篇 Blog 旨在汇总我的一些感悟，希望能为后来的学习者提供一些帮助。本系列文章主要基于南方科技大学吴雷老师的课程 MAE5002 高等数值分析。笔者从吴老师的课堂及讲义中获益良多，同时也得益于本科长安大学李琦老师在讲授计算方法时为我打下的坚实基础。正是因为有了前期的积累，在研究生再修这门课时，我才会有那种豁然开朗的感觉。在此，向二位老师致以诚挚的感谢。
笔者水平有限，文章更多用于记录个人的思考与输出。若文中出现纰漏或不严谨之处，还请大家多多包涵，并恳请批评指正！
在学习一门新课程时，我习惯先问自己三个问题：What? Why? How? 这门课是什么？为什么要学？学完怎么用？
带着问题去学习，能让你更准确地把握课程的脉络，而不是在学完后感到茫然。在学习过程中，你对这三个问题的认知会随着理解的加深而不断变化，这本身就是进步的体现。我们不能奢望一开始就掌握精髓，正是这种从模糊到清晰、不断优化的过程，才构成了真正的学习——不要为了学习而学习。
回到数值分析。在本科阶段，我就领悟到：数值分析实际上是在研究如何让计算机读懂真实的物理问题，并进行求解。
人类和计算机的思维方式截然不同。对于方程，人类偏爱解析解。比如一元二次方程，我们有完美的求根公式；但如果让你去求它的“数值解”，你可能反倒无从下手。而计算机恰恰相反，它难以处理复杂的符号推导以获得解析解，但它极其擅长海量的计算。
因此，我最初对这门课的理解就是：教会计算机去算方程的数值解。虽然现在回看这个想法略显简单，但这足以让初学者建立起初步的认知。在这个阶段，我采取的策略是大量的编程练习。要把程序写出来，你就必须理解算法的逻辑，而不是死记硬背。这为我打下了很好的基础。
然而，本科的学习更多停留在“算法”本身，忽略了背后的推导。这导致我虽然能解题，却难以深挖不同板块间的联系，始终抓不到重点。到了研究生阶段我才明白，忽略推导过程，就等于忽略了算法的来源。不知道它是怎么来的，自然就无法对其进行变形或优化，也失去了深入思考的空间。这或许是当时应试心理下的遗憾，但也正是这次重新学习的契机。
为什么要学这门课？因为我们需要解释物理世界。
物理定律往往通过方程来描述现实。高中时我们接触的大多是理想化、简化的系统，而真实的物理世界通常由微分方程来描述（例如傅里叶热传导定律）。我们可以尝试由简入繁地展开这个过程：
最简单的是一元线性方程（如描述小球在 x 方向的运动），移项即可求解。 接着是二元线性方程（x、y 方向的运动，或者经典的鸡兔同笼）。
对现在的你来说，解二元方程组是小菜一碟。但对计算机呢？你总不能针对每一个方程组手动调整代码。有人可能会想到用 for 循环，这确实可行，但当方程数量剧增时，这种方法既不优雅，效率也极低。
我们需要一种通用的范式。聪明的你可能已经想到了——线性代数。我们将方程组写成矩阵形式，利用线性代数的理论去求解。这一步，建立了线性方程组求解的基本思路。但通过学习你会发现，仅仅能算出结果是不够的，我们还必须考虑计算量和效率。真实世界的模拟（如有限元分析）往往涉及海量节点，形成巨大的方程组。如果一个算法能节省一半的时间，在算力昂贵的今天（想想 AI 的训练成本），其价值是巨大的。因此，数值分析的一个重要方向，就是研究如何提高线性方程组的求解效率。
解决了线性问题，非线性随之而来。 万有引力、电磁力是平方反比的，椭圆、双曲线的方程也不是线性的。一旦涉足真实世界，非线性方程无处不在。
对于二次方程，我们有求根公式。对于三次方程，其实也有，如下所示：
\[\begin{aligned} &ax^3+bx^2+cx+d=0 \quad (a\neq 0)\\[6pt] &\Delta_0=b^2-3ac,\qquad \Delta_1=2b^3-9abc+27a^2d\\[6pt] &C=\sqrt[3]{\frac{\Delta_1+\sqrt{\Delta_1^2-4\Delta_0^3}}{2}},\qquad \omega=\frac{-1+i\sqrt{3}}{2}\\[6pt] &x_k=-\frac{1}{3a} \left( b+\omega^k C+\frac{\Delta_0}{\omega^k C} \right), \quad k=0,1,2 \end{aligned}\]这公式又臭又长，根本记不住。而到了四次、五次甚至更高阶，解析解变得极其复杂甚至不存在。因此，让计算机通过解析方式求解是不现实的。计算机采用的是数值迭代的方式，例如二分法、牛顿法等。这便是数值分析中非线性方程求解的核心内容。同理，当涉及多个变量时（如椭圆与双曲线的交点），我们就会遇到非线性方程组，这同样是后续课程的重点。
计算机是离散的，它无法直接保存连续的值，只能存储一个个离散的点。这引出了另一个关键问题：如何处理连续与离散的关系？
这里就涉及到了插值。插值是通过已知的离散数据点，推算一定范围内新数据点的方法。举个简单的例子：如果你有三个离散点，想知道它们之间的值，最自然的思路是将两点连线。两点之间是精确的，但三个点呢？简单的连线可能无法平滑过渡。如果我们用二次函数去插值，就能找到一条经过这三个点的曲线，从而精确描述它们。插值的核心在于“精确经过已知点”，而拟合则是寻找一个函数来近似描述数据的整体趋势（不一定经过每个点），常用于理解数据的变化规律。
既然有了函数表达，我们自然可以讨论微分和积分。 微积分在高数中是连续的，建立在无穷小的概念上。而在数值方法中，它们变成了数值微分和数值积分。 回忆一下微积分的定义：微分源于斜率，积分源于曲线下的面积（黎曼和）。在计算机里，我们无法做到真正的无穷小，但我们可以用足够小的量去近似。通过插值的思想构造表达式，再进行微分或积分的运算，最后推广到微分方程的求解——这也是综合运用之前学到的各种方法（线性求解、非线性迭代、插值）的集大成者。
我希望通过这个系列，大家能建立起一个宏观的认知：数值分析的各个部分不是割裂的，而是由一套内在的逻辑和思想贯穿始终。
在这个 AI 飞速发展的时代，有人可能会问：既然 AI 能写代码，我们还需要学这些理论吗？我的答案是：非常需要。
如今的 AI 确实强大，但它需要逻辑清晰的 Prompt（提示词）以及准确的需求描述才能发挥作用。如果你对理论一知半解，很难向 AI 描述清楚你真正想要的东西，甚至会在代码出现问题时束手无策。AI 只能在已有的知识领域表现出色，而在面对一个全新的、需要深度定制的方向时，往往需要你提供清晰的理论框架。
AI 不是万能的。 如何让 AI 在你手中发挥最大作用，取决于你自身的理论深度。所以我们更应该去学习理论知识，而不是因为有了工具就放弃思考。
这是我的 Blog 开篇，也是我的一点浅显理解。水平有限，难免有瑕疵，但若能让一部分人通过数值分析这个系列有所收获，便是有意义的。我也希望大家保持批判性思考，不要对任何内容（无论是 AIGC 还是博客）全盘接受。看完、想过、内化，这才是属于自己的知识。
]]>