Five of the Most Useful AI Prompts for PV Engineers

Key points

AI is like a new colleague who has read almost every published paper but has never set foot in your factory. A prompt's job is to supply the context it lacks. Here are five copy-ready templates for failure analysis, standards interpretation, experiment design, data analysis and technical reports, plus three red lines for using AI.

Many colleagues tell us: "I tried AI. I asked why module power dropped after damp heat (DH), and got a pile of correct but useless answers: moisture ingress, encapsulant ageing, ribbon corrosion... all in the textbook, no help at all."

The problem usually isn't the AI; it's how you ask. Ask a new graduate the same question and you'll get the same answer. But if you explain the sample structure, test conditions, EL image features and the causes already ruled out, and then say you want an investigation table ranked by likelihood, what comes back is completely different.

AI is very much like that new colleague: it has read almost every published paper but has never set foot in your factory. Its knowledge is broad, but it knows nothing about the specific problem in front of you. A prompt's job is to fill in the missing context.

The five prompts below cover the five most common kinds of work in PV technical roles. Each is a template you can copy directly; just replace the content in [ ] with your own information.

Figure 1　Five prompts and the work they fit

00The structure first: a good prompt covers five things

Start with a general structure. The five templates look alike because useful prompts nearly always cover the same five things: role, context, task, constraints and output.

What engineers most often leave out is context and constraints. The more specific the context, the less generic the answer; and the most important constraint is always: if you're not sure, say so; don't make things up.

Figure 2　Five parts of a good prompt

01Failure analysis: turn symptoms into an investigation path

When to use it: abnormal power after reliability testing, dark spots or dark cells in EL, analysis of modules returned from the field.

Figure 3　Make the AI rank hypotheses, not list causes (illustrative content)

You are a crystalline silicon PV module failure analysis engineer with 15 years of experience.

[Context]
· Module construction: [cell type, size, layout; glass, encapsulant, backsheet or glass-glass material system]
· Stress conditions: [tests and conditions, e.g. DH1000, TC200, PID 96 h; or years in the field and climate type]
· Failure symptoms: [size of power loss; changes in Voc, Isc and FF separately; features and locations seen in EL, visual and IR inspection]
· Ruled out: [causes already excluded and the evidence]

[Task]
1. List all plausible failure-mechanism hypotheses, ranked from most to least likely;
2. For each hypothesis, state the existing evidence for it, the evidence against it, and what evidence is still missing;
3. For each hypothesis, give verification methods (e.g. EL/PL, IV curve analysis, SEM/EDS, cross-sectioning, wet leakage, encapsulant gel content or volume resistivity), with cost and lead time marked high or low;
4. Give an investigation order, "what first, what next", prioritising cheap tests that can rule out several hypotheses at once.

[Constraints]
· Reason only from the information I give. Where the information cannot distinguish between hypotheses, say so clearly rather than forcing a conclusion;
· Where specific values or literature findings are involved, state whether they are general industry experience or something I need to verify myself.

[Output]
A table (hypothesis / evidence for / evidence against / verification method / priority), plus investigation advice of no more than 200 words.

Why it is written this way:

• Give Voc, Isc and FF separately. "Power dropped 5%" carries almost no information. A drop in FF and a drop in Isc point to completely different mechanisms.
• Ask for "evidence against". AI tends by default to agree with you; forcing it to write counter-evidence makes it argue against itself first.
• Ask for ranking and cost. The hard part of failure analysis is often not thinking of causes but deciding which sample to cut first.

Follow-up

"If the verification result is [XXX], which hypotheses can be ruled out? Re-rank the rest." Feed back the results after each round of testing and let it help you converge step by step.

02Standards: turn clause text into a test plan

When to use it: launching a certification project, mapping differences between old and new editions, comparing requirements across markets, responding to customers' extended test requirements.

Figure 4　Standards questions: paste the text first, then ask (illustrative table)

You are a PV module certification engineer familiar with the IEC 61215 and IEC 61730 series.

Below is the standard text I have pasted:
[Paste the clause text, with standard number, edition year and clause number]

[Task]
1. In language an engineer can act on directly, explain each requirement of this text clause by clause: test conditions, number of samples, test sequence, pass criteria;
2. List anything in the clauses that is open to interpretation or easily misread;
3. For my product [product description, e.g. glass-glass n-type module, 1500 V system voltage], point out which requirements need special attention;
4. Compile a test plan table: test / conditions / samples / estimated duration / pass criteria / clause number.

[Constraints]
· Answer only from the text I have pasted. For anything it does not cover, mark it "not in the text; check the relevant standard" and do not fill in clause numbers or values from memory;
· Cite the clause in the text that each conclusion comes from.

[Output]
Clause-by-clause interpretation → easily misread points → test plan table.

Why it is written this way:

• Paste the text yourself. Clause numbers and values that AI quotes from memory are unreliable: editions get mixed up and numbers are wrong, stated with great confidence. Pasting the text and limiting it to "the pasted text only" is the safest way to handle standards questions.
• Paste both when comparing editions. Give it the old and new texts together and ask for a four-column table: "clause / old edition / new edition / impact on testing".
• Ask for clause numbers in the output. That lets you check each point. What the AI gives is a first draft; the standard text and the certification body's interpretation have the final say.

Follow-up

"Suppose I'm an engineer running this test for the first time. Where am I most likely to go wrong, in three places?" Good material for training new staff.

03Experiment design: build a validation matrix for a new material

When to use it: introducing a new encapsulant, backsheet, ribbon or flux; confirming a process window; assessing the reliability risk of a cost-down plan.

Figure 5　Work out what could be affected before choosing experiments

You are a PV module materials and process development engineer familiar with DOE methods and module reliability testing.

[Context]
· The change: [e.g. front encapsulant switched from supplier A's POE to supplier B's EPE]
· Purpose: [cost reduction / efficiency gain / second source / fixing a failure]
· Baseline: [current production BOM and key process parameters]
· Resource limits: [available samples, laminators, climate chamber capacity, target completion date]

[Task]
1. List the failure modes and performance metrics this change could affect, and explain the mechanisms;
2. From this, define the factors, levels and response variables to study, and say which factors may interact;
3. Within the resource limits, give an experiment matrix, stating whether to use full factorial, fractional factorial or one-factor comparison, and why;
4. Give validation tests at three levels (material, coupon and module), with suggested pass criteria for each level;
5. Point out the biggest risk in the plan and any tests I may have missed.

[Constraints]
· If the sample size cannot support statistical conclusions, say so directly; do not give a plan that looks rigorous but has no real statistical meaning;
· If pass criteria cite standard requirements, mark where I need to check the original text.

[Output]
Experiment matrix + three-level validation checklist + risk notes.

Why it is written this way:

• Failure modes first, experiment matrix second. Reverse the order and the AI will give you a neat but untargeted generic test list.
• Write in the resource limits. A DOE plan without constraints is always "test everything", while in reality the climate chambers always have a queue.
• The last question is the most valuable. Its answer to "tests I may have missed" is not always right, but it often points to an angle you hadn't considered.

Follow-up

"If I can keep only half the experiments, which should I cut, and what information would each cut lose?" Very useful when the project schedule gets squeezed.

04Data analysis: get the numbers right before discussing what they mean

When to use it: comparing IV data before and after reliability testing, line CTM variation, comparing degradation rates of different BOMs.

Figure 6　Break the power change down into Voc, Isc and FF (illustrative data, not measured)

You are a statistical analysis engineer familiar with PV module test data.

Below is the test data:
[Paste the table, or upload Excel / CSV. Explain each column, the units, the test equipment and test conditions]

[Context]
[Purpose of the experiment, grouping, number of samples per group, and which group is the control]

[Task]
1. First check data quality: missing values, obvious entry errors and outliers, listing each with your reasoning; do not remove outliers yourself;
2. For each group, calculate the change rates of Pmax, Voc, Isc and FF (mean, standard deviation, maximum, minimum);
3. Judge whether differences between groups are significant, stating the test used and whether its assumptions are met; if the sample size is too small, tell me directly;
4. Break the power change down into Voc, Isc and FF and identify the main contributor;
5. Choose suitable charts and plot them.

[Constraints]
· Write "what the data show" and "what this may mean" as two separate parts, clearly labelling the latter as speculation;
· Do all calculations in code, not mentally or by estimation, and show the working so I can check it.

[Output]
Data quality notes → statistics table → charts → observations → hypotheses to verify.

Why it is written this way:

• Don't drop "do it in code". Large language models make arithmetic mistakes when they "read" numbers directly. Having them write code to calculate makes both process and results checkable. Most mainstream AI tools can now run code and read uploaded spreadsheets, and this line pushes them onto the right tool.
• Separate facts from speculation. A difference across 3 samples is not the same as one across 30. A difference smaller than the test equipment's repeatability is no basis for a conclusion at all. Make it state these limitations.
• No removing outliers on its own. Outliers are often the entry point for failure analysis; whether to drop them is your call.

Follow-up

"Turn the analysis above into a one-page conclusion for management, keeping only three numbers." This leads straight into the next prompt.

05Technical reports: turn scattered material into a report you can send

When to use it: 8D reports, failure analysis reports, technical replies to customers, internal review documents.

Figure 7　You own the material and the evidence; the AI builds the structure

You are a senior technical engineer at a PV module company, skilled at writing technical reports for customers and management.

Below is my material:
[Paste the problem description, timeline, test data, analysis and actions taken. Scattered notes, emails and tables are all fine]

[Task]
Turn the material into a [8D report / failure analysis report / customer reply]:
1. The reader is [customer quality manager / company management / certification body], and what they care about most is [whether the root cause is found / how big the risk is / when it will be closed];
2. Organise it as [D1–D8 / background–analysis–conclusion–actions];
3. Open with the conclusion in three sentences, so someone who reads only the first paragraph still gets the key information;
4. In the root-cause section, show the full chain of evidence: symptom → hypothesis → verification → conclusion.

[Constraints]
· Use only the material I provide; do not add any data, dates or conclusions I have not given;
· For conclusions the material cannot support, list them separately at the end as "information still needed", rather than glossing over them with vague wording;
· Keep the tone professional and measured, neither evasive nor over-promising.

[Output]
Full report text + list of information still needed.

Why it is written this way:

• Name the reader and what they care about. The same failure analysis written for a customer and for your boss has completely different emphases.
• "Don't add anything I didn't give you" is the bottom line. A number in the report that you never measured has far worse consequences than a badly written report.
• "Information still needed" is a bonus. It amounts to a report review, showing you where the chain of evidence breaks.

Follow-up

"From the customer quality manager's point of view, raise the five toughest questions about this report." Let it pick holes before you send it.

06Finally, three red lines

Templates help, but three things matter more than any template.

Figure 8　Three red lines for using AI

• Confidentiality. Anonymise customer names, unpublished BOMs, formulations, process parameters and original test reports before uploading. Where your company has an AI policy, it takes precedence; prefer company-approved enterprise or on-premise tools.
• Verification. Check clause numbers, pass criteria and literature findings against the original sources every time. AI gives leads, not sources.
• Accountability. AI can help you think more completely and write faster, but you are the one who signs. Conclusions must be ones you accept after reviewing the data and thinking it through yourself.

07Final thoughts

AI remembers clauses and mechanisms better than anyone. But faced with a specific problem, what to ask, what to trust and what to do first still depend on the engineer. Now that the bar for "knowing" has been lowered, "judgement" is worth more than ever.

We suggest saving these five templates in your notes and using them whenever the matching situation comes up. After two or three uses, adapt them into your own versions.

Bottom line

Tell the AI exactly what you would tell a new colleague.

Do you have prompts that work well for you? We would be glad to hear from you.

Note: All figures and examples in this article are illustrative and do not represent real test results or failure conclusions. The templates work with mainstream conversational AI tools; results vary by tool and version.

PV Materials Lab

PV Materials Lab (光伏新材料研究所)
A PV R&D and technology team with 10+ years of experience | In-depth technical knowledge sharing
Materials · Reliability · Failure Analysis · Standards & Certification · Products · Processes
Exploring AI + PV; collaboration welcome

Disclaimer:
1. Original content reflects the authors' personal views only, is for reference only and does not constitute investment advice.
2. Reposted and cited content is credited to its source, out of respect for original work.
3. Some content was produced with AI assistance (chart generation, data retrieval, concept explanations, etc.); the core framework and key content were written by our technical team and reviewed by people.
4. If anything is inaccurate or infringes your rights, please leave a message or contact us and we will deal with it.